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

TP sysres IMA5sc 2018/2019 G10

2018-11-19T11:05:01Z

Eprofit :

=TP Systeme Reseau=
Vous trouverez sur cette page Wiki tous les travaux relatifs au cours de Systeme Reseau réalisés par '''Delobelle Matthieu'''
==TP Conteneur Reseau==

====Etapes de realisation des conteneurs (a la main)====
Creation d'un fichier (utilisé en tant que partition) de 10240 bloc de 1024k octets (Soit un fichier de 10Go)
dd if=/dev/zero of=disc.img bs=1024k count=10240

Creation d'un systeme d'un systeme de fichier linux au sein du fichier precedemment créé
mkfs disc.img

Creation des dossiers temporaires dans lequel le systeme sera monté
mkdir /tmp/fs1
mkdir /tmp/fs2
mkdir /tmp/fs3

Montage du systeme de fichier dans fs1
mount -o loop disc.img /tmp/fs1

La commande df -Ath permet d'avoir la liste des partitions montés par le systeme

[[Fichier:Df_ath.png]]

On voit bien que le /tmp/fs0 propose un emplacement memoire de 10Go

Bootstrap d'un systeme Debian au sein de la partition montée
debootstrap --include=apache2,vim,nano stable /tmp/fs1

Preparation du montage du systeme
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

Unmount de la partition
umount /tmp/fs1

(On remarque bien que la partition n'est plus montée via df -h)

Duplication de l'image deux fois, puis montage des trois systemes de fichier
cp disc.img disc2.img
cp disc.img disc3.img

mount -o loop disc.img /tmp/fs1
mount -o loop disc2.img /tmp/fs2
mount -o loop disc3.img /tmp/fs3

On verifie le resultat avec un autre df -h

Demarrage des conteneurs en chargeant les systemes de fichier.
unshare -n -u -p -f -m chroot /tmp/fs1 /bin/sh -c "mount /proc ; /bin/bash";
# La commande unshare permet de couper la liaison d'un processus avec les differentes tables de nom
# -n : table de nom reseau
# -u : table des hostnames

Si la creation du conteneur fonctionne bien : on ne peut pas revenir dans le dossier parent en faisant la commande 'cd ..', et de plus la commande ps ne retourne le resultat suivant :

[[Fichier:Ps.png]]

On voit bien qu'il n'y a pas d'autre processus lancé, on se trouve donc bien dans le conteneur

En lancant donc les trois conteneurs, chacun est alors independant de l'autre, et l'on peut lancer la commande suivante pour voir "l'existence" des trois conteneurs
ps aux | grep unshare

==== Mise en réseau des conteneurs ====
Creation du bridge (commutateur virtuel) sur la machine hote
ip link add bridge2 type bridge

Sur la machine hote, on crée également les différentes interfaces réseaux (une par conteneur + une pour le mandataire)
ip link add vif1 type veth peer name eth0@vif1 #conteneur 1
ip link add vif2 type veth peer name eth0@vif2 #conteneur 2
ip link add vif3 type veth peer name eth0@vif3 #conteneur 3
ip link add vif4 type veth peer name eth1@vif4 #mandataire

Ajout puis activation des differentes interfaces reseaux dans leur bridge respectif.
ip link set vif1 master bridge2
ip link set vif2 master bridge2
ip link set vif3 master bridge2
ip link set vif4 master bridge

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up

On recupere les PID des differents conteneurs
ps aux | grep unshare
[[Fichier:Grepunshare.png]]

Il est necessaire "d'envoyer" les differentes interfaces reseaux a leur conteneur respectif
ip link set eth0@vif1 netns /proc/[PID CONTENEUR 1]/ns/net name eth0 #conteneur 1
ip link set eth0@vif2 netns /proc/[PID CONTENEUR 2]/ns/net name eth0 #conteneur 2
ip link set eth0@vif3 netns /proc/[PID CONTENEUR 3]/ns/net name eth0 #conteneur 3

On ajoute ensuite les adresses IP a chaque conteneur

Dans le conteneur 1
ip addr add 192.168.1.11/24 dev eth0
ip link set eth0 up
ip link set lo up

Dans le conteneur 2
ip addr add 192.168.1.12/24 dev eth0
ip link set eth0 up
ip link set lo up

Dans le conteneur 3
ip addr add 192.168.1.13/24 dev eth0
ip link set eth0 up
ip link set lo up

On peut donc alors parfaitement pinger les conteneurs entre eux ainsi qu'avec la machine hote

On ajoute egalement l'interface eth1 au conteneur 3 qui servira de mandataire

ip link set eth1@vif4 netns /proc/[PID CONTENEUR 3]/ns/net name eth1
ip addr add 172.26.145.140/24 dev eth1
ip link set eth1 up

==== Mise en place des mandataires inverses ====

==TP Conteneur Reseau==

====Etapes de realisation des conteneurs (a la main)====
Creation d'un fichier (utilisé en tant que partition) de 10240 bloc de 1024k octets (Soit un fichier de 10Go)
dd if=/dev/zero of=disc.img bs=1024k count=10240

Creation d'un systeme d'un systeme de fichier linux au sein du fichier precedemment créé
mkfs disc.img

Creation des dossiers temporaires dans lequel le systeme sera monté
mkdir /tmp/fs1
mkdir /tmp/fs2
mkdir /tmp/fs3

Montage du systeme de fichier dans fs1
mount -o loop disc.img /tmp/fs1

La commande df -Ath permet d'avoir la liste des partitions montés par le systeme

[[Fichier:Df_ath.png]]

On voit bien que le /tmp/fs0 propose un emplacement memoire de 10Go

Bootstrap d'un systeme Debian au sein de la partition montée
debootstrap --include=apache2,vim,nano stable /tmp/fs1

Preparation du montage du systeme
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

Unmount de la partition
umount /tmp/fs1

(On remarque bien que la partition n'est plus montée via df -h)

Duplication de l'image deux fois, puis montage des trois systemes de fichier
cp disc.img disc2.img
cp disc.img disc3.img

mount -o loop disc.img /tmp/fs1
mount -o loop disc2.img /tmp/fs2
mount -o loop disc3.img /tmp/fs3

On verifie le resultat avec un autre df -h

[[Fichier:Dfh2.png]]

Demarrage des conteneurs en chargeant les systemes de fichier.
unshare -n -u -p -f -m chroot /tmp/fs1 /bin/sh -c "mount /proc ; /bin/bash";
# La commande unshare permet de couper la liaison d'un processus avec les differentes tables de nom
# -n : table de nom reseau
# -u : table des hostnames

Si la creation du conteneur fonctionne bien : on ne peut pas revenir dans le dossier parent en faisant la commande 'cd ..', et de plus la commande ps ne retourne le resultat suivant :

[[Fichier:Ps.png]]

On voit bien qu'il n'y a pas d'autre processus lancé, on se trouve donc bien dans le conteneur

En lancant donc les trois conteneurs, chacun est alors independant de l'autre, et l'on peut lancer la commande suivante pour voir "l'existence" des trois conteneurs
ps aux | grep unshare

[[Fichier:Psaux.png]]

==== Mise en réseau des conteneurs ====
Creation du bridge (commutateur virtuel) sur la machine hote
ip link add bridge2 type bridge

Sur la machine hote, on crée également les différentes interfaces réseaux (une par conteneur + une pour le mandataire)
ip link add vif1 type veth peer name eth0@vif1 #conteneur 1
ip link add vif2 type veth peer name eth0@vif2 #conteneur 2
ip link add vif3 type veth peer name eth0@vif3 #conteneur 3
ip link add vif4 type veth peer name eth1@vif4 #mandataire

Ajout puis activation des differentes interfaces reseaux dans leur bridge respectif.
ip link set vif1 master bridge2
ip link set vif2 master bridge2
ip link set vif3 master bridge2
ip link set vif4 master bridge

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up

On recupere les PID des differents conteneurs
ps aux | grep unshare
[[Fichier:Grepunshare.png]]

Il est necessaire "d'envoyer" les differentes interfaces reseaux a leur conteneur respectif
ip link set eth0@vif1 netns /proc/[PID CONTENEUR 1]/ns/net name eth0 #conteneur 1
ip link set eth0@vif2 netns /proc/[PID CONTENEUR 2]/ns/net name eth0 #conteneur 2
ip link set eth0@vif3 netns /proc/[PID CONTENEUR 3]/ns/net name eth0 #conteneur 3

On ajoute ensuite les adresses IP a chaque conteneur

Dans le conteneur 1
ip addr add 192.168.1.11/24 dev eth0
ip link set eth0 up
ip link set lo up

Dans le conteneur 2
ip addr add 192.168.1.12/24 dev eth0
ip link set eth0 up
ip link set lo up

Dans le conteneur 3
ip addr add 192.168.1.13/24 dev eth0
ip link set eth0 up
ip link set lo up

On peut donc alors parfaitement pinger les conteneurs entre eux ainsi qu'avec la machine hote

On ajoute egalement l'interface eth1 au conteneur 3 qui servira de mandataire

ip link set eth1@vif4 netns /proc/[PID CONTENEUR 3]/ns/net name eth1
ip addr add 172.26.145.140/24 dev eth1
ip link set eth1 up

==== Mise en place des mandataires inverses ====

Configuration du fichier sites-enables/000-default.conf du mandataire inverse (conteneur 3)

<VirtualHost *:80>
ServerName oli.plil.space
ServerAdmin webmaster@localhost
ProxyPass / http://192.168.0.4
ProxyPassRever / http://192.168.0.4
ProxyRequests Off
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
<VirtualHost *:80>
ServerName eti.plil.space
ServerAdmin webmaster@localhost
ProxyPass / http://192.168.0.3
ProxyPassRever / http://192.168.0.3
ProxyRequests Off
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

11h10 => Serveurs Web unshare OK

TP sysres IMA5sc 2018/2019 G10

2018-11-19T11:03:59Z

Eprofit :

=TP Systeme Reseau=
Vous trouverez sur cette page Wiki tous les travaux relatifs au cours de Systeme Reseau réalisés par '''Delobelle Matthieu'''
==TP Conteneur Reseau==

====Etapes de realisation des conteneurs (a la main)====
Creation d'un fichier (utilisé en tant que partition) de 10240 bloc de 1024k octets (Soit un fichier de 10Go)
dd if=/dev/zero of=disc.img bs=1024k count=10240

Creation d'un systeme d'un systeme de fichier linux au sein du fichier precedemment créé
mkfs disc.img

Creation des dossiers temporaires dans lequel le systeme sera monté
mkdir /tmp/fs1
mkdir /tmp/fs2
mkdir /tmp/fs3

Montage du systeme de fichier dans fs1
mount -o loop disc.img /tmp/fs1

La commande df -Ath permet d'avoir la liste des partitions montés par le systeme

[[Fichier:Df_ath.png]]

On voit bien que le /tmp/fs0 propose un emplacement memoire de 10Go

Bootstrap d'un systeme Debian au sein de la partition montée
debootstrap --include=apache2,vim,nano stable /tmp/fs1

Preparation du montage du systeme
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

Unmount de la partition
umount /tmp/fs1

(On remarque bien que la partition n'est plus montée via df -h)

Duplication de l'image deux fois, puis montage des trois systemes de fichier
cp disc.img disc2.img
cp disc.img disc3.img

mount -o loop disc.img /tmp/fs1
mount -o loop disc2.img /tmp/fs2
mount -o loop disc3.img /tmp/fs3

On verifie le resultat avec un autre df -h

[[Fichier:Dfh2.png]]

Demarrage des conteneurs en chargeant les systemes de fichier.
unshare -n -u -p -f -m chroot /tmp/fs1 /bin/sh -c "mount /proc ; /bin/bash";
# La commande unshare permet de couper la liaison d'un processus avec les differentes tables de nom
# -n : table de nom reseau
# -u : table des hostnames

Si la creation du conteneur fonctionne bien : on ne peut pas revenir dans le dossier parent en faisant la commande 'cd ..', et de plus la commande ps ne retourne le resultat suivant :

[[Fichier:Ps.png]]

On voit bien qu'il n'y a pas d'autre processus lancé, on se trouve donc bien dans le conteneur

En lancant donc les trois conteneurs, chacun est alors independant de l'autre, et l'on peut lancer la commande suivante pour voir "l'existence" des trois conteneurs
ps aux | grep unshare

[[Fichier:Psaux.png]]

==== Mise en réseau des conteneurs ====
Creation du bridge (commutateur virtuel) sur la machine hote
ip link add bridge2 type bridge

Sur la machine hote, on crée également les différentes interfaces réseaux (une par conteneur + une pour le mandataire)
ip link add vif1 type veth peer name eth0@vif1 #conteneur 1
ip link add vif2 type veth peer name eth0@vif2 #conteneur 2
ip link add vif3 type veth peer name eth0@vif3 #conteneur 3
ip link add vif4 type veth peer name eth1@vif4 #mandataire

Ajout puis activation des differentes interfaces reseaux dans leur bridge respectif.
ip link set vif1 master bridge2
ip link set vif2 master bridge2
ip link set vif3 master bridge2
ip link set vif4 master bridge

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up

On recupere les PID des differents conteneurs
ps aux | grep unshare
[[Fichier:Grepunshare.png]]

Il est necessaire "d'envoyer" les differentes interfaces reseaux a leur conteneur respectif
ip link set eth0@vif1 netns /proc/[PID CONTENEUR 1]/ns/net name eth0 #conteneur 1
ip link set eth0@vif2 netns /proc/[PID CONTENEUR 2]/ns/net name eth0 #conteneur 2
ip link set eth0@vif3 netns /proc/[PID CONTENEUR 3]/ns/net name eth0 #conteneur 3

On ajoute ensuite les adresses IP a chaque conteneur

Dans le conteneur 1
ip addr add 192.168.1.11/24 dev eth0
ip link set eth0 up
ip link set lo up

Dans le conteneur 2
ip addr add 192.168.1.12/24 dev eth0
ip link set eth0 up
ip link set lo up

Dans le conteneur 3
ip addr add 192.168.1.13/24 dev eth0
ip link set eth0 up
ip link set lo up

On peut donc alors parfaitement pinger les conteneurs entre eux ainsi qu'avec la machine hote

On ajoute egalement l'interface eth1 au conteneur 3 qui servira de mandataire

ip link set eth1@vif4 netns /proc/[PID CONTENEUR 3]/ns/net name eth1
ip addr add 172.26.145.140/24 dev eth1
ip link set eth1 up

==== Mise en place des mandataires inverses ====

==TP Conteneur Reseau==

====Etapes de realisation des conteneurs (a la main)====
Creation d'un fichier (utilisé en tant que partition) de 10240 bloc de 1024k octets (Soit un fichier de 10Go)
dd if=/dev/zero of=disc.img bs=1024k count=10240

Creation d'un systeme d'un systeme de fichier linux au sein du fichier precedemment créé
mkfs disc.img

Creation des dossiers temporaires dans lequel le systeme sera monté
mkdir /tmp/fs1
mkdir /tmp/fs2
mkdir /tmp/fs3

Montage du systeme de fichier dans fs1
mount -o loop disc.img /tmp/fs1

La commande df -Ath permet d'avoir la liste des partitions montés par le systeme

[[Fichier:Df_ath.png]]

On voit bien que le /tmp/fs0 propose un emplacement memoire de 10Go

Bootstrap d'un systeme Debian au sein de la partition montée
debootstrap --include=apache2,vim,nano stable /tmp/fs1

Preparation du montage du systeme
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

Unmount de la partition
umount /tmp/fs1

(On remarque bien que la partition n'est plus montée via df -h)

Duplication de l'image deux fois, puis montage des trois systemes de fichier
cp disc.img disc2.img
cp disc.img disc3.img

mount -o loop disc.img /tmp/fs1
mount -o loop disc2.img /tmp/fs2
mount -o loop disc3.img /tmp/fs3

On verifie le resultat avec un autre df -h

[[Fichier:Dfh2.png]]

Demarrage des conteneurs en chargeant les systemes de fichier.
unshare -n -u -p -f -m chroot /tmp/fs1 /bin/sh -c "mount /proc ; /bin/bash";
# La commande unshare permet de couper la liaison d'un processus avec les differentes tables de nom
# -n : table de nom reseau
# -u : table des hostnames

Si la creation du conteneur fonctionne bien : on ne peut pas revenir dans le dossier parent en faisant la commande 'cd ..', et de plus la commande ps ne retourne le resultat suivant :

[[Fichier:Ps.png]]

On voit bien qu'il n'y a pas d'autre processus lancé, on se trouve donc bien dans le conteneur

En lancant donc les trois conteneurs, chacun est alors independant de l'autre, et l'on peut lancer la commande suivante pour voir "l'existence" des trois conteneurs
ps aux | grep unshare

[[Fichier:Psaux.png]]

==== Mise en réseau des conteneurs ====
Creation du bridge (commutateur virtuel) sur la machine hote
ip link add bridge2 type bridge

Sur la machine hote, on crée également les différentes interfaces réseaux (une par conteneur + une pour le mandataire)
ip link add vif1 type veth peer name eth0@vif1 #conteneur 1
ip link add vif2 type veth peer name eth0@vif2 #conteneur 2
ip link add vif3 type veth peer name eth0@vif3 #conteneur 3
ip link add vif4 type veth peer name eth1@vif4 #mandataire

Ajout puis activation des differentes interfaces reseaux dans leur bridge respectif.
ip link set vif1 master bridge2
ip link set vif2 master bridge2
ip link set vif3 master bridge2
ip link set vif4 master bridge

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up

On recupere les PID des differents conteneurs
ps aux | grep unshare
[[Fichier:Grepunshare.png]]

Il est necessaire "d'envoyer" les differentes interfaces reseaux a leur conteneur respectif
ip link set eth0@vif1 netns /proc/[PID CONTENEUR 1]/ns/net name eth0 #conteneur 1
ip link set eth0@vif2 netns /proc/[PID CONTENEUR 2]/ns/net name eth0 #conteneur 2
ip link set eth0@vif3 netns /proc/[PID CONTENEUR 3]/ns/net name eth0 #conteneur 3

On ajoute ensuite les adresses IP a chaque conteneur

Dans le conteneur 1
ip addr add 192.168.1.11/24 dev eth0
ip link set eth0 up
ip link set lo up

Dans le conteneur 2
ip addr add 192.168.1.12/24 dev eth0
ip link set eth0 up
ip link set lo up

Dans le conteneur 3
ip addr add 192.168.1.13/24 dev eth0
ip link set eth0 up
ip link set lo up

On peut donc alors parfaitement pinger les conteneurs entre eux ainsi qu'avec la machine hote

On ajoute egalement l'interface eth1 au conteneur 3 qui servira de mandataire

ip link set eth1@vif4 netns /proc/[PID CONTENEUR 3]/ns/net name eth1
ip addr add 172.26.145.140/24 dev eth1
ip link set eth1 up

==== Mise en place des mandataires inverses ====

Configuration du fichier sites-enables/000-default.conf du mandataire inverse (conteneur 3)

<VirtualHost *:80>
ServerName oli.plil.space
ServerAdmin webmaster@localhost
ProxyPass / http://192.168.0.4
ProxyPassRever / http://192.168.0.4
ProxyRequests Off
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
<VirtualHost *:80>
ServerName eti.plil.space
ServerAdmin webmaster@localhost
ProxyPass / http://192.168.0.3
ProxyPassRever / http://192.168.0.3
ProxyRequests Off
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

11h10 => Serveurs Web unshare OK

TP sysres IMA5sc 2018/2019 G10

2018-11-19T11:00:49Z

Eprofit : Page créée avec « =TP Systeme Reseau= Vous trouverez sur cette page Wiki tous les travaux relatifs au cours de Systeme Reseau réalisés par '''Delobelle Matthieu''' ==TP Conteneur Reseau==... »

=TP Systeme Reseau=
Vous trouverez sur cette page Wiki tous les travaux relatifs au cours de Systeme Reseau réalisés par '''Delobelle Matthieu'''
==TP Conteneur Reseau==

====Etapes de realisation des conteneurs (a la main)====
Creation d'un fichier (utilisé en tant que partition) de 10240 bloc de 1024k octets (Soit un fichier de 10Go)
dd if=/dev/zero of=disc.img bs=1024k count=10240

Creation d'un systeme d'un systeme de fichier linux au sein du fichier precedemment créé
mkfs disc.img

Creation des dossiers temporaires dans lequel le systeme sera monté
mkdir /tmp/fs1
mkdir /tmp/fs2
mkdir /tmp/fs3

Montage du systeme de fichier dans fs1
mount -o loop disc.img /tmp/fs1

La commande df -Ath permet d'avoir la liste des partitions montés par le systeme

[[Fichier:Df_ath.png]]

On voit bien que le /tmp/fs0 propose un emplacement memoire de 10Go

Bootstrap d'un systeme Debian au sein de la partition montée
debootstrap --include=apache2,vim,nano stable /tmp/fs1

Preparation du montage du systeme
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

Unmount de la partition
umount /tmp/fs1

(On remarque bien que la partition n'est plus montée via df -h)

Duplication de l'image deux fois, puis montage des trois systemes de fichier
cp disc.img disc2.img
cp disc.img disc3.img

mount -o loop disc.img /tmp/fs1
mount -o loop disc2.img /tmp/fs2
mount -o loop disc3.img /tmp/fs3

On verifie le resultat avec un autre df -h

[[Fichier:Dfh2.png]]

Demarrage des conteneurs en chargeant les systemes de fichier.
unshare -n -u -p -f -m chroot /tmp/fs1 /bin/sh -c "mount /proc ; /bin/bash";
# La commande unshare permet de couper la liaison d'un processus avec les differentes tables de nom
# -n : table de nom reseau
# -u : table des hostnames

Si la creation du conteneur fonctionne bien : on ne peut pas revenir dans le dossier parent en faisant la commande 'cd ..', et de plus la commande ps ne retourne le resultat suivant :

[[Fichier:Ps.png]]

On voit bien qu'il n'y a pas d'autre processus lancé, on se trouve donc bien dans le conteneur

En lancant donc les trois conteneurs, chacun est alors independant de l'autre, et l'on peut lancer la commande suivante pour voir "l'existence" des trois conteneurs
ps aux | grep unshare

[[Fichier:Psaux.png]]

==== Mise en réseau des conteneurs ====
Creation du bridge (commutateur virtuel) sur la machine hote
ip link add bridge2 type bridge

Sur la machine hote, on crée également les différentes interfaces réseaux (une par conteneur + une pour le mandataire)
ip link add vif1 type veth peer name eth0@vif1 #conteneur 1
ip link add vif2 type veth peer name eth0@vif2 #conteneur 2
ip link add vif3 type veth peer name eth0@vif3 #conteneur 3
ip link add vif4 type veth peer name eth1@vif4 #mandataire

Ajout puis activation des differentes interfaces reseaux dans leur bridge respectif.
ip link set vif1 master bridge2
ip link set vif2 master bridge2
ip link set vif3 master bridge2
ip link set vif4 master bridge

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up

On recupere les PID des differents conteneurs
ps aux | grep unshare
[[Fichier:Grepunshare.png]]

Il est necessaire "d'envoyer" les differentes interfaces reseaux a leur conteneur respectif
ip link set eth0@vif1 netns /proc/[PID CONTENEUR 1]/ns/net name eth0 #conteneur 1
ip link set eth0@vif2 netns /proc/[PID CONTENEUR 2]/ns/net name eth0 #conteneur 2
ip link set eth0@vif3 netns /proc/[PID CONTENEUR 3]/ns/net name eth0 #conteneur 3

On ajoute ensuite les adresses IP a chaque conteneur

Dans le conteneur 1
ip addr add 192.168.1.11/24 dev eth0
ip link set eth0 up
ip link set lo up

Dans le conteneur 2
ip addr add 192.168.1.12/24 dev eth0
ip link set eth0 up
ip link set lo up

Dans le conteneur 3
ip addr add 192.168.1.13/24 dev eth0
ip link set eth0 up
ip link set lo up

On peut donc alors parfaitement pinger les conteneurs entre eux ainsi qu'avec la machine hote

On ajoute egalement l'interface eth1 au conteneur 3 qui servira de mandataire

ip link set eth1@vif4 netns /proc/[PID CONTENEUR 3]/ns/net name eth1
ip addr add 172.26.145.140/24 dev eth1
ip link set eth1 up

==== Mise en place des mandataires inverses ====

==TP Conteneur Reseau==

====Etapes de realisation des conteneurs (a la main)====
Creation d'un fichier (utilisé en tant que partition) de 10240 bloc de 1024k octets (Soit un fichier de 10Go)
dd if=/dev/zero of=disc.img bs=1024k count=10240

Creation d'un systeme d'un systeme de fichier linux au sein du fichier precedemment créé
mkfs disc.img

Creation des dossiers temporaires dans lequel le systeme sera monté
mkdir /tmp/fs1
mkdir /tmp/fs2
mkdir /tmp/fs3

Montage du systeme de fichier dans fs1
mount -o loop disc.img /tmp/fs1

La commande df -Ath permet d'avoir la liste des partitions montés par le systeme

[[Fichier:Df_ath.png]]

On voit bien que le /tmp/fs0 propose un emplacement memoire de 10Go

Bootstrap d'un systeme Debian au sein de la partition montée
debootstrap --include=apache2,vim,nano stable /tmp/fs1

Preparation du montage du systeme
echo "proc /proc proc defaults 0 0" >> rootfs/etc/fstab

Unmount de la partition
umount /tmp/fs1

(On remarque bien que la partition n'est plus montée via df -h)

Duplication de l'image deux fois, puis montage des trois systemes de fichier
cp disc.img disc2.img
cp disc.img disc3.img

mount -o loop disc.img /tmp/fs1
mount -o loop disc2.img /tmp/fs2
mount -o loop disc3.img /tmp/fs3

On verifie le resultat avec un autre df -h

[[Fichier:Dfh2.png]]

Demarrage des conteneurs en chargeant les systemes de fichier.
unshare -n -u -p -f -m chroot /tmp/fs1 /bin/sh -c "mount /proc ; /bin/bash";
# La commande unshare permet de couper la liaison d'un processus avec les differentes tables de nom
# -n : table de nom reseau
# -u : table des hostnames

Si la creation du conteneur fonctionne bien : on ne peut pas revenir dans le dossier parent en faisant la commande 'cd ..', et de plus la commande ps ne retourne le resultat suivant :

[[Fichier:Ps.png]]

On voit bien qu'il n'y a pas d'autre processus lancé, on se trouve donc bien dans le conteneur

En lancant donc les trois conteneurs, chacun est alors independant de l'autre, et l'on peut lancer la commande suivante pour voir "l'existence" des trois conteneurs
ps aux | grep unshare

[[Fichier:Psaux.png]]

==== Mise en réseau des conteneurs ====
Creation du bridge (commutateur virtuel) sur la machine hote
ip link add bridge2 type bridge

Sur la machine hote, on crée également les différentes interfaces réseaux (une par conteneur + une pour le mandataire)
ip link add vif1 type veth peer name eth0@vif1 #conteneur 1
ip link add vif2 type veth peer name eth0@vif2 #conteneur 2
ip link add vif3 type veth peer name eth0@vif3 #conteneur 3
ip link add vif4 type veth peer name eth1@vif4 #mandataire

Ajout puis activation des differentes interfaces reseaux dans leur bridge respectif.
ip link set vif1 master bridge2
ip link set vif2 master bridge2
ip link set vif3 master bridge2
ip link set vif4 master bridge

ip link set vif1 up
ip link set vif2 up
ip link set vif3 up
ip link set vif4 up

On recupere les PID des differents conteneurs
ps aux | grep unshare
[[Fichier:Grepunshare.png]]

Il est necessaire "d'envoyer" les differentes interfaces reseaux a leur conteneur respectif
ip link set eth0@vif1 netns /proc/[PID CONTENEUR 1]/ns/net name eth0 #conteneur 1
ip link set eth0@vif2 netns /proc/[PID CONTENEUR 2]/ns/net name eth0 #conteneur 2
ip link set eth0@vif3 netns /proc/[PID CONTENEUR 3]/ns/net name eth0 #conteneur 3

On ajoute ensuite les adresses IP a chaque conteneur

Dans le conteneur 1
ip addr add 192.168.1.11/24 dev eth0
ip link set eth0 up
ip link set lo up

Dans le conteneur 2
ip addr add 192.168.1.12/24 dev eth0
ip link set eth0 up
ip link set lo up

Dans le conteneur 3
ip addr add 192.168.1.13/24 dev eth0
ip link set eth0 up
ip link set lo up

On peut donc alors parfaitement pinger les conteneurs entre eux ainsi qu'avec la machine hote

On ajoute egalement l'interface eth1 au conteneur 3 qui servira de mandataire

ip link set eth1@vif4 netns /proc/[PID CONTENEUR 3]/ns/net name eth1
ip addr add 172.26.145.140/24 dev eth1
ip link set eth1 up

==== Mise en place des mandataires inverses ====

Configuration du fichier sites-enables/000-default.conf du mandataire inverse (conteneur 3)

<VirtualHost *:80>
ServerName azeroth.plil.space
ServerAdmin webmaster@mdelobel.plil.space
ProxyPass / http://192.168.1.11
ProxyPassRever / http://192.168.1.11
ProxyRequests Off
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>
<VirtualHost *:80>
ServerName argus.plil.space
ServerAdmin webmaster@mdelobel.plil.space
ProxyPass / http://192.168.1.12
ProxyPassRever / http://192.168.1.12
ProxyRequests Off
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

11h => Serveurs Web unshare OK (pb a du recommencer voir Ji)

TP sysres IMA5sc 2018/2019

2018-11-19T11:00:27Z

Eprofit :

== Répartition des binômes ==

{| class="wikitable"
! Cahier !! Elèves
|-
| [[ TP sysres IMA5sc 2018/2019 G1 | Cahier groupe n°1]]
| Taky Djeraba & Baptiste Cartier
|-
| [[ TP sysres IMA5sc 2018/2019 G2 | Cahier groupe n°2]]
| Jade Dupont & Quentin Boëns
|-
| [[ TP sysres IMA5sc 2018/2019 G3 | Cahier groupe n°3]]
| Antoine Duquenoy & Anthony Durot
|-
| [[ TP sysres IMA5sc 2018/2019 G4 | Cahier groupe n°4]]
| Paul Ribeiro & Antoine Untereiner
|-
| [[ TP sysres IMA5sc 2018/2019 G5 | Cahier groupe n°5]]
| Delobelle Matthieu
|-
| [[ TP sysres IMA5sc 2018/2019 G6 | Cahier groupe n°6]]
| Simon Feutrier & Antoine Gosse
|-
| [[ TP sysres IMA5sc 2018/2019 G7 | Cahier groupe n°7]]
| Naif Mehanna & Maxime Créteur
|-
| [[ TP sysres IMA5sc 2018/2019 G8 | Cahier groupe n°8]]
| Justine Senellart & Rodolphe Toin
|-
| [[ TP sysres IMA5sc 2018/2019 G9 | Cahier groupe n°9]]
| Amine El Messaoudi & Thibault Cattelain
|-
| [[ TP sysres IMA5sc 2018/2019 G10 | Cahier groupe n°10]]
| Etienne Profit & Olivier Mahieux
|-
| [[ TP sysres IMA5sc 2018/2019 G11 | Cahier groupe n°11]]
| Prénom Nom & Prénom Nom
|-
| [[ TP sysres IMA5sc 2018/2019 G12 | Cahier groupe n°12]]
| Benjamin Canu & Amaury Carval
|-
| [[ TP sysres IMA5sc 2018/2019 G13 | Cahier groupe n°13]]
| Ji YANG
|-
|}

IMA4 2016/2017 P31

2017-05-03T18:51:07Z

Eprofit : /* Feuille d'heures */

__TOC__
 
==Cahier des charges==

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

L'enceinte de Polytech Lille est bien connue de ses occupants, élèves ou professeurs. Cependant, pour un nouvel arrivant, qu'il soit simple visiteur ou conférencier, se rendre dans la salle D'Arsonval ou simplement trouver une place libre sur le parking peut se révéler être une épreuve. L’intérêt de notre projet est de faciliter à ces derniers l'accès à tous les recoins des bâtiments de Polytech Lille grâce à l'utilisation d'un drone d'accueil personnalisé.

====Objectifs du projet====

L'objectif de notre projet est, à terme, de pouvoir guider un utilisateur de l'entrée du parking de Polytech jusqu'à une salle à l'intérieur de l'enceinte de l'école. La réalisation de ce projet passe par deux objectifs intermédiaires :

* Accueillir un visiteur depuis l'entrée du parking de Polytech et le mener jusqu'à une place de parking libre.
* Guider ce même visiteur depuis sa place de parking jusqu'à une salle.

Il est envisageable de pouvoir réaliser le second objectif dans les deux sens, à savoir : guider un visiteur d'une salle de Polytech jusqu'à sa place de parking.

====Description du projet====

Nous disposons d'un drone Phantom3 d'1,2 Kg capable de supporter une charge utile d'1Kg. Nous devons utiliser cette charge utile à bon escient afin de ne pas perdre en autonomie. Nous envisageons donc d'utiliser environ 500g de matériel à monter sur le drone. Le système final doit remplir les fonctions suivantes :

* L'utilisateur devra pouvoir choisir sa destination via une interface portable soit par Bluetooth entre un téléphone mobile sur lequel sera préalablement installé une application soit par le biais d'une page internet hébergée sur une Raspberry.
* Le drone se déplacera à une hauteur conséquente et sera capable d'éviter et de contourner les obstacles présents sur son chemin.
* Le drone devra pouvoir se repérer automatiquement à l'extérieur.

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

Nous utiliserons probablement la plateforme ROS (Robot Operating System), qui nous permet d'utiliser différents modules (par exemple le SLAM). Nous aurons aussi recours à des bases de données, afin de recenser les utilisateurs, les salles, etc ; nécessitant alors une machine capable de les gérer via un logiciel du type MySQL.

[[Fichier:Dji3.jpg|400px|vignette|Alt=oui|Drone DJI Phantom3 Advanced ]]

Afin de réaliser notre projet, nous envisageons d'utiliser :

* un drone modèle Phantom3, fourni par Polytech Lille, cœur de notre projet ;

* une carte Raspberry, sur laquelle l'utilisateur pourra se connecter et accéder à la page d'accueil du drone ;

* un GPS, déjà intégré au drone, pour le localiser en permanence ;

* un écran LCD, que nous monterons sur le drone afin de faciliter l'utilisation du drone par le visiteur ;

* un module Wi-Fi ESP8266, afin de créer un serveur ouvert à tous ;

* un jeu de capteurs de proximité (Ultrasons/Infrarouge), afin de garantir l'intégrité physique du personnel et matérielle du drone.

 
 
 
 
 
 
 
 
 
 

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

* Préliminaires :
** Étude du mode de communication entre le drone et l'application qui lui est dédiée.
** Étude de ROS (Robot Operating System) et des algorithmes de SLAM pour voir si ces composants logiciels peuvent faciliter le développement du projet.
** Installation de ROS sur RaspberryPi.

* Partie 1 :
** Installation du SDK de DJI.
** Essais sur les capteurs de proximité qui seront couplés à la RaspberryPi.
** Gestion d'un itinéraire par le drone, plus précisément la gestion d'un vol automatique avec le Phantom3.
** Communication drone/capteur par le biais de la carte RaspberryPi.
** Identification d'une personne grâce à une connexion Bluetooth entre un visiteur et la Raspberry.
** Mener une voiture à sa place de parking grâce aux éléments travaillés précédemment.

* Partie 2 :
** Se repérer dans Polytech grâce à un algorithme de SLAM intégré à la Raspberry.
** Se rendre dans une salle donnée en partant de l'entrée de Polytech. (coté parking)

<gallery>
Fichier:Gantt_partie_1.png| Gantt P31 partie 1 (''Cliquez pour agrandir'')
Fichier:Gantt_partie_2.png| Gantt P31 partie 2 (''Cliquez pour agrandir'')
Fichier:Gantt_partie_3.png| Gantt P31 partie 3 (''Cliquez pour agrandir'')
</gallery>

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 2h
|
|
|
|
|
|
|
|
|
|
|
|-
| Installation du SDK DJI et de Android Studio, téléchargement de tous les packages manquants
|
|
| 4h
|
|
|
|
|
|
|
|
|
|-
| Etude des différents moyens de communication avec le drone
|
| 4h
|
|
|
|
|
|
|
|
|
|
|-
| Etude des capteurs via arduino
|
|
|
|
|
|
| 3h
|
|
|
|
|
|-
| Choix et implémentation des trajets dans l'application
|
|
|
|
|
|
|
|
|
| 4h
|
|
|-
| Construction du code principal de l'application
|
|
|
|
|
|
|
|
|
|
| 8h
|
|}

==Avancement du Projet==

===Semaine 1===

*Correction du cahier des charges.
 
*Établissement de la liste du matériel nécessaire à la réalisation de notre projet.
Pour ce projet, nous pensons qu'il serait en effet judicieux d'acheter du matériel supplémentaire afin de mener à bien notre projet. Il serait question d'utiliser:

* Carte RaspberryPi 3. Ce modèle est équipé d'un module bluetooth afin d'assurer la communication entre l'utilisateur et le drone, ainsi qu'entre le drone et les capteurs.

* 3 Capteurs de mesure Sharp GP2Y0A02YK. (référence : [http://www.gotronic.fr/art-capteur-de-mesure-sharp-gp2y0a02yk-11536.htm]). Nous avons choisi ce capteur sur 2 critères: Le prix et la plage de détection. En effet, il nous fallait un capteur de proximité ayant une plage de détection maximale entre 1 et 2 mètres afin que le drone puisse détecter les obstacles assez tôt pour pouvoir les éviter.

*Appareil mobile sous OS Android (portable ou tablette ). Cet appareil mobile pourra nous servir à installer les applications qui gérerons le drone. C'est également sur ce téléphone que sera gérer la base de données des itinéraires nécessaires aux déplacement du drone jusque à une place de parking.
 
[[Fichier:Djimode.jpg|right|400px|vignette|Alt=oui|Exemple du mode POI de DJI.]]
 
*Étude des différents modes de fonctionnement du drone (Point Of Interest, Homelock, etc).

 
Le mode POI présenté ci-contre pourrait par exemple être utilisé dans le cas où le drone serait arrivé à sa destination. Il attendrait en vol que la voiture se soit garé à sa place.
Nous pourrions également définir les places de parking comme des "homes" que le drone rejoindrait en suivant un itinéraire pré-défini et où il attendrait que la voiture arrive.
 
*Première découverte de ROS pour l'installer sur RaspberryPi.

Robot Operating System (ROS) est une plateforme de développement logicielle pour utilisée en robotique.[http://www.ros.org/]. Il s'agit d'un pseudo OS qui peut fonctionner sur ordinateur. ROS a pour intérêt d'offrir des fonctionnalités telles abstraction du matériel, le contrôle des périphériques de bas niveau, mise en œuvre de fonctionnalités couramment utilisées ainsi que la transmission de messages entre les processus.
 
La communication entre les processus s'opère de la façon suivante:
[[Fichier:ROScom.png|center|400px]]

Un premier node avertit le master qu'il a une donnée à partager. -> Un deuxième node avertit le master qu'il souhaite avoir accès à une donnée. 
Une connexion entre les deux nodes est créée. -> Le premier node peut envoyer des données au second.

L'implémentation d'un OS ROS sur une RaspberryPi pourrait donc être une bonne idée qu'il faudrait continuer à creuser afin de faire communiquer la Raspberry et le drone.

===Semaine 2===
*Approfondissement de l'étude du drone phantom3 de DJI.
*Suite à des problèmes au niveau de la communication avec le drone, une solution alternative est envisagée. Il s'agirait de concevoir nous même notre propre drone.
*Préparation d'un argumentaire à présenter aux encadrants du projet.

===Semaine 3===
*Nous envisageons désormais de créer une application permettant de communiquer avec le drone. Nous faisons donc des recherches autour de l'API du drone.
*Découverte du SDK (Software Development Kit ) proposé par le site "DJI-developper" qui permet de créer des applications pouvant communiquer avec notre drone.
*Installation de Android studio, application nécessaire à la création des applications via le SDK de DJI-developper.

===Semaine 4===
*Installation du SDK de DJI-developper sur notre ordinateur portable.

===Semaine 5===
*Nous tentons de créer une application Android permettant de diriger le drone Phantom3 en pointant au doigt sur un appareil mobile un emplacement sur une carte virtuelle. L'application est développée via Android Studio, et son code nous est fourni par le site DJI-developper (https://developer.dji.com/mobile-sdk/documentation/android-tutorials/GSDemo-Google-Map.html), site regroupant un ensemble non négligeable de codes exemple, dont celui que nous utilisons ici.

===Semaine 6===
*Lors de cette semaine nous rencontrons de nombreux problèmes avec le drone. En effet, il nous est impossible de faire démarrer les moteurs.Nous sommes donc dans l'impossibilité de tester l'application que nous venons terminer de coder. Nous nous lançons donc dans une phase de recherche au travers du manuel d'utilisation et d'internet afin de debugger notre drone. Après quelques recherches, nous pensons que le firmware de la télécommande ou du drone a besoin d'être updaté. Nous mettons donc à jour le drone. Le problème est que nous n'arrivons plus à faire communiquer l'API avec le drone car nous sommes constamment "déconnectés" malgré que le câble soit relié entre notre téléphone et le drone. Or, pour mettre à jour notre drone, nous devons avoir touts les éléments connectés.
*En parallèle, nous avons reçu nos capteurs de proximité. Nous décidons donc de commencer la partie communication capteur-Raspberry. Nous rencontrons de nouveau des problèmes, en effet nous n'arrivons pas à communiquer avec la Raspberry via la liaison série. La solution est de mettre dans le fichier "config.txt" de la partition /boot une ligne de commande < enable_uart = 1 > et < core_freq = 250 > afin de lancer dès le démarrage de la Raspberry la liaison série qui n'est plus lancée par défaut sur les Raspberry Pi 3.

===Semaine 7===
*Premier vols avec le drone. Nous le testons dehors en volant tout d'abord en mode manuel, c'est-à-dire en utilisant la télécommande fournie. Après nous être familiarisé avec le drone et ses déplacements, nous essayons maintenant de le faire voler en utilisant notre application. Cette application est installée sur un téléphone portable sous Android, de plus, ce téléphone est connecté par liaison filaire avec la télécommande afin d'assurer la communication entre le drone et le téléphone.
 
[[Fichier:cartedjigo.png||vignette|Alt=oui||left| Interface de l'application ]]

 
 
 
Cette application permet entre autre :
* De localiser le drone sur la carte mondiale tirée de Google Map. Une fois localisé, le drone est symbolisé par un avion sur la carte.
* De définir des paramètres de vols du drone tels que l'altitude de vol ou la vitesse de vol.
* De créer des "Waypoints", ou "points d’intérêt. Ces points sont définis par l’utilisateur en cliquant sur l'écran tactile du téléphone. Il peut définir autant de points qu'il désire. Lorsque le drone décollera, il ira à chacun des points d'intérêt définis.
* Lorsque les Waypoints et les paramètres de vols sont définis, et une fois que la mission a bien été compilée en appuyant sur la touche "Prepare", l'utilisateur peut lancer la session de vol en appuyant sur "Start".
 
<gallery>
Fichier:MenuAppP31.png| Menu paramètres de l'application (''Cliquez pour agrandir'')
</gallery>

 
 
La vidéo suivante montre le résultat d'un plan de vol en 2 "Waypoints". L'altitude est définie à 5m et la vitesse de vol à "lent":
 
https://drive.google.com/open?id=0ByKP9w_p1fHAR09EVFozZjVvRlE

 
* En parallèle, nous entamons également le travail sur le capteur de proximité couplé à la raspberry. Après quelques recherches, nous trouvons le schéma de montage suivant que nous allons réutiliser:
[[Fichier:Rasp.PNG|center ]]
 
 

===Semaine 8===

* Nous continuons la configuration de la Raspberry Pi3 afin de pouvoir utiliser le GPIO et lire les valeurs reçues sur les pins. Pour cela, nous devons tout d'abord relier la carte avec le réseau afin de pouvoir installer des paquets. Pour cela nous écrivons dans le fichier /etc/dhcpcd.conf les lignes suivantes:
 
[[Fichier:StaticPI.png|center]]
 
Nous allons désormais installer le paquet "wiringPi". Ce wiringPi est un outil qui permet de contrôler les différentes broches du port GPIO. Il permet entre autre de visualiser les valeurs et les fonctions de chaque pin du gpio et de changer mode en entrée ou en sortie. Cet outil est donc bien utile pour configurer notre Raspberry.
 
[[Fichier:PinPi.png|center]]
 
Un problème apparaît directement lorsque nous regardons le tableau. En effet, la colonne 'V' du tableau indique que la valeur sur la pin est de 1. Or, cette valeur reste la même lorsque l'obstacle bouge. cela signifie qu'il y a un système de seuil dans la Raspberry qui fait qu'au delà d'une certaine valeur, le signal détecté est un 1 logique. Pour remédier à ce problème, nous utilisons donc un convertisseur Analogique-Digital.
 
 
[[Fichier:Sensor.jpg|200px]] 
Ce convertisseur sur 12-bits va nous permettre de convertir la valeur analogique du capteur de proximité et de l'envoyer à la Raspberry. De plus, ce convertisseur possède 4 entrées analogiques, ce qui est suffisant pour accueillir nos 3 capteurs de proximités.

 
Après avoir installé quelques librairies et installé python sur notre carte, nous entamons la création d'un programme qui lira la valeur du capteur 1 (branché sur l'entrée analogique 0 ) et l'affiche dans le terminal. Nous nous servons de quelques programmes exemple trouvés sur internet afin de nous aider. Le résultat est le suivant: 
[[Fichier:Pyth.png]]
[[Fichier:Capteur1.JPG|400px]]

* Cette semaine nous avons étudié plus en détails le corps du programme principal de l'application. Celui-ci contient une vingtaine de fonctions remplissant des tâches diverses et variées :
- Une fonction permettant d'ajouter un marqueur sur la carte du monde à l'endroit ou l'utilisateur clique, 
- Une fonction permettant d'ouvrir un sous-menu pour fixer les caractéristiques du vol, 
- Une fonction permettant de valider les waypoints (WP) indiqués par l'utilisateur et de préparer le plan de vol, 
- Et plus d'une dizaine d'autres fonctions que nous ne détaillerons pas ici car leur utilité dans le cadre de ce projet est moindre. 

L'objectif des prochaines séances et de réaliser à partir de ce code l'application finale qui nous permettra, via l'appui sur un UNIQUE bouton de l'écran, d'à la fois choisir une place, de créer le plan de vol, et de faire décoller le drone. Afin de réaliser cet objectif, nous avons utilisé la fonction "addWaypointMarker (?)" : cette fonction, initialement, permettait d'autoriser l'ajout de WP sur l'écran, puis un second appui sur cette même touche sauvegardait les marqueurs puis interdisait l'ajout de nouveaux WP (jusqu'au prochain appui sur ce bouton) ; dorénavant un appui sur ce bouton permet à la fois de créer automatiquement les WP associés au parcours jusqu'à une place libre, de créer le plan de vol, puis de faire démarrer le drone.

'''(Ajouter photo du code ici)'''

===Semaine 9===
*Cette semaine nous nous attaquons à la création d'un support pour nos capteurs. Le but de ce support est d'accueillir nos 3 capteurs, la Raspberry Pi3 ainsi que le convertisseur Analogique-Digital. Ce support dit être le plus léger possible et prendre le moins de place possible.
Nous utilisons donc du balza, une sorte de bois léger utilisé pour le modélisme pour fabriquer entre autre les maquettes d'avions:
 
 
[[Fichier:Nacelle.JPG|600px]]
 
 
Comme indiqué précédemment lors de la dernière semaine. La lecture de la valeur d'un capteur passe un programme Python. Il faut désormais lire la valeur des 2 autres capteurs pour les afficher.De nombreux exemples sont disponibles sur la toile et le langage Python est assez intuitif. Nous arrivons rapidement au code suivant: 
 
[[Fichier:Programme_Python.png|500px]] 
Il a tout d'abord fallu importer la librairie RPi.GPIO qui permet de gérer les entrées/sorties du GPIO de la raspberry. A partir de là, le programme est assez simple, la seule difficulté est de retrouver les bons code qui correspondent à un convertisseur ADS1015. Ici le programme affiche la valeur de chaque capteur ( droit, avant ou gauche ) et si celle ci est trop petite, affiche un message puis allume la LED de la breadboard. 
Une temporisation a été nécessaire afin d'apercevoir l'allumage de la LED et surtout afin d'éviter de surcharger le buffer. 
 
Le résultat retourné sur le terminal est le suivant: 
[[Fichier:NacelleFin.png|400px|center]]
 
En conclusion: 
* Nous disposons d'une nacelle de 300 grammes qui pourra être embarquée par le drone. Celle ci détecte un obstacle jusque à 1 mètre apparaissant dans un angle de 130° à l'avant du drone.
* L'utilisation d'une batterie externe a été privilégiée afin d'éviter une trop grosse perte d'autonomie du drone si la raspberry avait été alimenté par le drone (via un câble double micro-usb).
* Un problème est parfois rencontré lorsque nous lançons le programme à cause de la communication i2c entre l'ADC et la raspberry. Ce problème est soit dû à la non libération du canal de transmission à la fin du programme soit dû à des adresses mémoires "volatiles".
* Il faut maintenant chercher un moyen de faire communiquer cette nacelle avec le téléphone afin d'envoyer une commande de stop au drone. La communication bluetooth ne sera pas utilisée car sa portée est trop courte. Nous essayerons donc de communiquer par Wi-fi. Nous savons qu'il est possible de faire communiquer un téléphone et une raspberry. Nous allons donc désormais orienter nos recherches vers l'envoi d'une variable via Wi-fi.

* Du coté de l'application, la grosse partie du travail de cette semaine aura été d'implémenter dans le code de celle-ci des tableaux contenant les coordonnées GPS des places de parking que nous avons soigneusement sélectionné. L'idée est simple : nous avons une superposition de tableaux :
1. Le tableau principal est le tableau de places,
2. Ce tableau de places contient un certain nombre de sous-tableaux,
3. Enfin, chaque sous-tableau contient la longitude et la latitude d'un point "clé" du chemin que suivra le drone jusqu'à la place caractérisée.

Ici, nous avons fais le choix (logique) de ne pas implémenter la totalité des places du parking, mais seulement un échantillon d'une demi-douzaine de places, situées à des endroits assez espacés du parking. De plus, par soucis d'équité, nous avons ajouté un tableau copié sur le premier, mais contenant uniquement les coordonnées de places pour handicapés.

== Fichiers Rendus ==

IMA4 2016/2017 P31

2017-05-03T18:47:17Z

Eprofit : /* Semaine 9 */

__TOC__
 
==Cahier des charges==

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

L'enceinte de Polytech Lille est bien connue de ses occupants, élèves ou professeurs. Cependant, pour un nouvel arrivant, qu'il soit simple visiteur ou conférencier, se rendre dans la salle D'Arsonval ou simplement trouver une place libre sur le parking peut se révéler être une épreuve. L’intérêt de notre projet est de faciliter à ces derniers l'accès à tous les recoins des bâtiments de Polytech Lille grâce à l'utilisation d'un drone d'accueil personnalisé.

====Objectifs du projet====

L'objectif de notre projet est, à terme, de pouvoir guider un utilisateur de l'entrée du parking de Polytech jusqu'à une salle à l'intérieur de l'enceinte de l'école. La réalisation de ce projet passe par deux objectifs intermédiaires :

* Accueillir un visiteur depuis l'entrée du parking de Polytech et le mener jusqu'à une place de parking libre.
* Guider ce même visiteur depuis sa place de parking jusqu'à une salle.

Il est envisageable de pouvoir réaliser le second objectif dans les deux sens, à savoir : guider un visiteur d'une salle de Polytech jusqu'à sa place de parking.

====Description du projet====

Nous disposons d'un drone Phantom3 d'1,2 Kg capable de supporter une charge utile d'1Kg. Nous devons utiliser cette charge utile à bon escient afin de ne pas perdre en autonomie. Nous envisageons donc d'utiliser environ 500g de matériel à monter sur le drone. Le système final doit remplir les fonctions suivantes :

* L'utilisateur devra pouvoir choisir sa destination via une interface portable soit par Bluetooth entre un téléphone mobile sur lequel sera préalablement installé une application soit par le biais d'une page internet hébergée sur une Raspberry.
* Le drone se déplacera à une hauteur conséquente et sera capable d'éviter et de contourner les obstacles présents sur son chemin.
* Le drone devra pouvoir se repérer automatiquement à l'extérieur.

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

Nous utiliserons probablement la plateforme ROS (Robot Operating System), qui nous permet d'utiliser différents modules (par exemple le SLAM). Nous aurons aussi recours à des bases de données, afin de recenser les utilisateurs, les salles, etc ; nécessitant alors une machine capable de les gérer via un logiciel du type MySQL.

[[Fichier:Dji3.jpg|400px|vignette|Alt=oui|Drone DJI Phantom3 Advanced ]]

Afin de réaliser notre projet, nous envisageons d'utiliser :

* un drone modèle Phantom3, fourni par Polytech Lille, cœur de notre projet ;

* une carte Raspberry, sur laquelle l'utilisateur pourra se connecter et accéder à la page d'accueil du drone ;

* un GPS, déjà intégré au drone, pour le localiser en permanence ;

* un écran LCD, que nous monterons sur le drone afin de faciliter l'utilisation du drone par le visiteur ;

* un module Wi-Fi ESP8266, afin de créer un serveur ouvert à tous ;

* un jeu de capteurs de proximité (Ultrasons/Infrarouge), afin de garantir l'intégrité physique du personnel et matérielle du drone.

 
 
 
 
 
 
 
 
 
 

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

* Préliminaires :
** Étude du mode de communication entre le drone et l'application qui lui est dédiée.
** Étude de ROS (Robot Operating System) et des algorithmes de SLAM pour voir si ces composants logiciels peuvent faciliter le développement du projet.
** Installation de ROS sur RaspberryPi.

* Partie 1 :
** Installation du SDK de DJI.
** Essais sur les capteurs de proximité qui seront couplés à la RaspberryPi.
** Gestion d'un itinéraire par le drone, plus précisément la gestion d'un vol automatique avec le Phantom3.
** Communication drone/capteur par le biais de la carte RaspberryPi.
** Identification d'une personne grâce à une connexion Bluetooth entre un visiteur et la Raspberry.
** Mener une voiture à sa place de parking grâce aux éléments travaillés précédemment.

* Partie 2 :
** Se repérer dans Polytech grâce à un algorithme de SLAM intégré à la Raspberry.
** Se rendre dans une salle donnée en partant de l'entrée de Polytech. (coté parking)

<gallery>
Fichier:Gantt_partie_1.png| Gantt P31 partie 1 (''Cliquez pour agrandir'')
Fichier:Gantt_partie_2.png| Gantt P31 partie 2 (''Cliquez pour agrandir'')
Fichier:Gantt_partie_3.png| Gantt P31 partie 3 (''Cliquez pour agrandir'')
</gallery>

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 2h
|
|
|
|
|
|
|
|
|
|
|
|-
| Installation du SDK DJI et de Android Studio, téléchargement de tous les packages manquants
|
|
| 4h
|
|
|
|
|
|
|
|
|
|-
| Etude des différents moyens de communication avec le drone
|
| 4h
|
|
|
|
|
|
|
|
|
|
|-
| Etude des capteurs via arduino
|
|
|
|
|
|
| 3h
|
|
|
|
|
|}

==Avancement du Projet==

===Semaine 1===

*Correction du cahier des charges.
 
*Établissement de la liste du matériel nécessaire à la réalisation de notre projet.
Pour ce projet, nous pensons qu'il serait en effet judicieux d'acheter du matériel supplémentaire afin de mener à bien notre projet. Il serait question d'utiliser:

* Carte RaspberryPi 3. Ce modèle est équipé d'un module bluetooth afin d'assurer la communication entre l'utilisateur et le drone, ainsi qu'entre le drone et les capteurs.

* 3 Capteurs de mesure Sharp GP2Y0A02YK. (référence : [http://www.gotronic.fr/art-capteur-de-mesure-sharp-gp2y0a02yk-11536.htm]). Nous avons choisi ce capteur sur 2 critères: Le prix et la plage de détection. En effet, il nous fallait un capteur de proximité ayant une plage de détection maximale entre 1 et 2 mètres afin que le drone puisse détecter les obstacles assez tôt pour pouvoir les éviter.

*Appareil mobile sous OS Android (portable ou tablette ). Cet appareil mobile pourra nous servir à installer les applications qui gérerons le drone. C'est également sur ce téléphone que sera gérer la base de données des itinéraires nécessaires aux déplacement du drone jusque à une place de parking.
 
[[Fichier:Djimode.jpg|right|400px|vignette|Alt=oui|Exemple du mode POI de DJI.]]
 
*Étude des différents modes de fonctionnement du drone (Point Of Interest, Homelock, etc).

 
Le mode POI présenté ci-contre pourrait par exemple être utilisé dans le cas où le drone serait arrivé à sa destination. Il attendrait en vol que la voiture se soit garé à sa place.
Nous pourrions également définir les places de parking comme des "homes" que le drone rejoindrait en suivant un itinéraire pré-défini et où il attendrait que la voiture arrive.
 
*Première découverte de ROS pour l'installer sur RaspberryPi.

Robot Operating System (ROS) est une plateforme de développement logicielle pour utilisée en robotique.[http://www.ros.org/]. Il s'agit d'un pseudo OS qui peut fonctionner sur ordinateur. ROS a pour intérêt d'offrir des fonctionnalités telles abstraction du matériel, le contrôle des périphériques de bas niveau, mise en œuvre de fonctionnalités couramment utilisées ainsi que la transmission de messages entre les processus.
 
La communication entre les processus s'opère de la façon suivante:
[[Fichier:ROScom.png|center|400px]]

Un premier node avertit le master qu'il a une donnée à partager. -> Un deuxième node avertit le master qu'il souhaite avoir accès à une donnée. 
Une connexion entre les deux nodes est créée. -> Le premier node peut envoyer des données au second.

L'implémentation d'un OS ROS sur une RaspberryPi pourrait donc être une bonne idée qu'il faudrait continuer à creuser afin de faire communiquer la Raspberry et le drone.

===Semaine 2===
*Approfondissement de l'étude du drone phantom3 de DJI.
*Suite à des problèmes au niveau de la communication avec le drone, une solution alternative est envisagée. Il s'agirait de concevoir nous même notre propre drone.
*Préparation d'un argumentaire à présenter aux encadrants du projet.

===Semaine 3===
*Nous envisageons désormais de créer une application permettant de communiquer avec le drone. Nous faisons donc des recherches autour de l'API du drone.
*Découverte du SDK (Software Development Kit ) proposé par le site "DJI-developper" qui permet de créer des applications pouvant communiquer avec notre drone.
*Installation de Android studio, application nécessaire à la création des applications via le SDK de DJI-developper.

===Semaine 4===
*Installation du SDK de DJI-developper sur notre ordinateur portable.

===Semaine 5===
*Nous tentons de créer une application Android permettant de diriger le drone Phantom3 en pointant au doigt sur un appareil mobile un emplacement sur une carte virtuelle. L'application est développée via Android Studio, et son code nous est fourni par le site DJI-developper (https://developer.dji.com/mobile-sdk/documentation/android-tutorials/GSDemo-Google-Map.html), site regroupant un ensemble non négligeable de codes exemple, dont celui que nous utilisons ici.

===Semaine 6===
*Lors de cette semaine nous rencontrons de nombreux problèmes avec le drone. En effet, il nous est impossible de faire démarrer les moteurs.Nous sommes donc dans l'impossibilité de tester l'application que nous venons terminer de coder. Nous nous lançons donc dans une phase de recherche au travers du manuel d'utilisation et d'internet afin de debugger notre drone. Après quelques recherches, nous pensons que le firmware de la télécommande ou du drone a besoin d'être updaté. Nous mettons donc à jour le drone. Le problème est que nous n'arrivons plus à faire communiquer l'API avec le drone car nous sommes constamment "déconnectés" malgré que le câble soit relié entre notre téléphone et le drone. Or, pour mettre à jour notre drone, nous devons avoir touts les éléments connectés.
*En parallèle, nous avons reçu nos capteurs de proximité. Nous décidons donc de commencer la partie communication capteur-Raspberry. Nous rencontrons de nouveau des problèmes, en effet nous n'arrivons pas à communiquer avec la Raspberry via la liaison série. La solution est de mettre dans le fichier "config.txt" de la partition /boot une ligne de commande < enable_uart = 1 > et < core_freq = 250 > afin de lancer dès le démarrage de la Raspberry la liaison série qui n'est plus lancée par défaut sur les Raspberry Pi 3.

===Semaine 7===
*Premier vols avec le drone. Nous le testons dehors en volant tout d'abord en mode manuel, c'est-à-dire en utilisant la télécommande fournie. Après nous être familiarisé avec le drone et ses déplacements, nous essayons maintenant de le faire voler en utilisant notre application. Cette application est installée sur un téléphone portable sous Android, de plus, ce téléphone est connecté par liaison filaire avec la télécommande afin d'assurer la communication entre le drone et le téléphone.
 
[[Fichier:cartedjigo.png||vignette|Alt=oui||left| Interface de l'application ]]

 
 
 
Cette application permet entre autre :
* De localiser le drone sur la carte mondiale tirée de Google Map. Une fois localisé, le drone est symbolisé par un avion sur la carte.
* De définir des paramètres de vols du drone tels que l'altitude de vol ou la vitesse de vol.
* De créer des "Waypoints", ou "points d’intérêt. Ces points sont définis par l’utilisateur en cliquant sur l'écran tactile du téléphone. Il peut définir autant de points qu'il désire. Lorsque le drone décollera, il ira à chacun des points d'intérêt définis.
* Lorsque les Waypoints et les paramètres de vols sont définis, et une fois que la mission a bien été compilée en appuyant sur la touche "Prepare", l'utilisateur peut lancer la session de vol en appuyant sur "Start".
 
<gallery>
Fichier:MenuAppP31.png| Menu paramètres de l'application (''Cliquez pour agrandir'')
</gallery>

 
 
La vidéo suivante montre le résultat d'un plan de vol en 2 "Waypoints". L'altitude est définie à 5m et la vitesse de vol à "lent":
 
https://drive.google.com/open?id=0ByKP9w_p1fHAR09EVFozZjVvRlE

 
* En parallèle, nous entamons également le travail sur le capteur de proximité couplé à la raspberry. Après quelques recherches, nous trouvons le schéma de montage suivant que nous allons réutiliser:
[[Fichier:Rasp.PNG|center ]]
 
 

===Semaine 8===

* Nous continuons la configuration de la Raspberry Pi3 afin de pouvoir utiliser le GPIO et lire les valeurs reçues sur les pins. Pour cela, nous devons tout d'abord relier la carte avec le réseau afin de pouvoir installer des paquets. Pour cela nous écrivons dans le fichier /etc/dhcpcd.conf les lignes suivantes:
 
[[Fichier:StaticPI.png|center]]
 
Nous allons désormais installer le paquet "wiringPi". Ce wiringPi est un outil qui permet de contrôler les différentes broches du port GPIO. Il permet entre autre de visualiser les valeurs et les fonctions de chaque pin du gpio et de changer mode en entrée ou en sortie. Cet outil est donc bien utile pour configurer notre Raspberry.
 
[[Fichier:PinPi.png|center]]
 
Un problème apparaît directement lorsque nous regardons le tableau. En effet, la colonne 'V' du tableau indique que la valeur sur la pin est de 1. Or, cette valeur reste la même lorsque l'obstacle bouge. cela signifie qu'il y a un système de seuil dans la Raspberry qui fait qu'au delà d'une certaine valeur, le signal détecté est un 1 logique. Pour remédier à ce problème, nous utilisons donc un convertisseur Analogique-Digital.
 
 
[[Fichier:Sensor.jpg|200px]] 
Ce convertisseur sur 12-bits va nous permettre de convertir la valeur analogique du capteur de proximité et de l'envoyer à la Raspberry. De plus, ce convertisseur possède 4 entrées analogiques, ce qui est suffisant pour accueillir nos 3 capteurs de proximités.

 
Après avoir installé quelques librairies et installé python sur notre carte, nous entamons la création d'un programme qui lira la valeur du capteur 1 (branché sur l'entrée analogique 0 ) et l'affiche dans le terminal. Nous nous servons de quelques programmes exemple trouvés sur internet afin de nous aider. Le résultat est le suivant: 
[[Fichier:Pyth.png]]
[[Fichier:Capteur1.JPG|400px]]

* Cette semaine nous avons étudié plus en détails le corps du programme principal de l'application. Celui-ci contient une vingtaine de fonctions remplissant des tâches diverses et variées :
- Une fonction permettant d'ajouter un marqueur sur la carte du monde à l'endroit ou l'utilisateur clique, 
- Une fonction permettant d'ouvrir un sous-menu pour fixer les caractéristiques du vol, 
- Une fonction permettant de valider les waypoints (WP) indiqués par l'utilisateur et de préparer le plan de vol, 
- Et plus d'une dizaine d'autres fonctions que nous ne détaillerons pas ici car leur utilité dans le cadre de ce projet est moindre. 

L'objectif des prochaines séances et de réaliser à partir de ce code l'application finale qui nous permettra, via l'appui sur un UNIQUE bouton de l'écran, d'à la fois choisir une place, de créer le plan de vol, et de faire décoller le drone. Afin de réaliser cet objectif, nous avons utilisé la fonction "addWaypointMarker (?)" : cette fonction, initialement, permettait d'autoriser l'ajout de WP sur l'écran, puis un second appui sur cette même touche sauvegardait les marqueurs puis interdisait l'ajout de nouveaux WP (jusqu'au prochain appui sur ce bouton) ; dorénavant un appui sur ce bouton permet à la fois de créer automatiquement les WP associés au parcours jusqu'à une place libre, de créer le plan de vol, puis de faire démarrer le drone.

'''(Ajouter photo du code ici)'''

===Semaine 9===
*Cette semaine nous nous attaquons à la création d'un support pour nos capteurs. Le but de ce support est d'accueillir nos 3 capteurs, la Raspberry Pi3 ainsi que le convertisseur Analogique-Digital. Ce support dit être le plus léger possible et prendre le moins de place possible.
Nous utilisons donc du balza, une sorte de bois léger utilisé pour le modélisme pour fabriquer entre autre les maquettes d'avions:
 
 
[[Fichier:Nacelle.JPG|600px]]
 
 
Comme indiqué précédemment lors de la dernière semaine. La lecture de la valeur d'un capteur passe un programme Python. Il faut désormais lire la valeur des 2 autres capteurs pour les afficher.De nombreux exemples sont disponibles sur la toile et le langage Python est assez intuitif. Nous arrivons rapidement au code suivant: 
 
[[Fichier:Programme_Python.png|500px]] 
Il a tout d'abord fallu importer la librairie RPi.GPIO qui permet de gérer les entrées/sorties du GPIO de la raspberry. A partir de là, le programme est assez simple, la seule difficulté est de retrouver les bons code qui correspondent à un convertisseur ADS1015. Ici le programme affiche la valeur de chaque capteur ( droit, avant ou gauche ) et si celle ci est trop petite, affiche un message puis allume la LED de la breadboard. 
Une temporisation a été nécessaire afin d'apercevoir l'allumage de la LED et surtout afin d'éviter de surcharger le buffer. 
 
Le résultat retourné sur le terminal est le suivant: 
[[Fichier:NacelleFin.png|400px|center]]
 
En conclusion: 
* Nous disposons d'une nacelle de 300 grammes qui pourra être embarquée par le drone. Celle ci détecte un obstacle jusque à 1 mètre apparaissant dans un angle de 130° à l'avant du drone.
* L'utilisation d'une batterie externe a été privilégiée afin d'éviter une trop grosse perte d'autonomie du drone si la raspberry avait été alimenté par le drone (via un câble double micro-usb).
* Un problème est parfois rencontré lorsque nous lançons le programme à cause de la communication i2c entre l'ADC et la raspberry. Ce problème est soit dû à la non libération du canal de transmission à la fin du programme soit dû à des adresses mémoires "volatiles".
* Il faut maintenant chercher un moyen de faire communiquer cette nacelle avec le téléphone afin d'envoyer une commande de stop au drone. La communication bluetooth ne sera pas utilisée car sa portée est trop courte. Nous essayerons donc de communiquer par Wi-fi. Nous savons qu'il est possible de faire communiquer un téléphone et une raspberry. Nous allons donc désormais orienter nos recherches vers l'envoi d'une variable via Wi-fi.

* Du coté de l'application, la grosse partie du travail de cette semaine aura été d'implémenter dans le code de celle-ci des tableaux contenant les coordonnées GPS des places de parking que nous avons soigneusement sélectionné. L'idée est simple : nous avons une superposition de tableaux :
1. Le tableau principal est le tableau de places,
2. Ce tableau de places contient un certain nombre de sous-tableaux,
3. Enfin, chaque sous-tableau contient la longitude et la latitude d'un point "clé" du chemin que suivra le drone jusqu'à la place caractérisée.

Ici, nous avons fais le choix (logique) de ne pas implémenter la totalité des places du parking, mais seulement un échantillon d'une demi-douzaine de places, situées à des endroits assez espacés du parking. De plus, par soucis d'équité, nous avons ajouté un tableau copié sur le premier, mais contenant uniquement les coordonnées de places pour handicapés.

== Fichiers Rendus ==

IMA4 2016/2017 P31

2017-04-26T13:44:14Z

Eprofit :

__TOC__
 
==Cahier des charges==

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

L'enceinte de Polytech Lille est bien connue de ses occupants, élèves ou professeurs. Cependant, pour un nouvel arrivant, qu'il soit simple visiteur ou conférencier, se rendre dans la salle D'Arsonval ou simplement trouver une place libre sur le parking peut se révéler être une épreuve. L’intérêt de notre projet est de faciliter à ces derniers l'accès à tous les recoins des bâtiments de Polytech Lille grâce à l'utilisation d'un drone d'accueil personnalisé.

====Objectifs du projet====

L'objectif de notre projet est, à terme, de pouvoir guider un utilisateur de l'entrée du parking de Polytech jusqu'à une salle à l'intérieur de l'enceinte de l'école. La réalisation de ce projet passe par deux objectifs intermédiaires :

* Accueillir un visiteur depuis l'entrée du parking de Polytech et le mener jusqu'à une place de parking libre.
* Guider ce même visiteur depuis sa place de parking jusqu'à une salle.

Il est envisageable de pouvoir réaliser le second objectif dans les deux sens, à savoir : guider un visiteur d'une salle de Polytech jusqu'à sa place de parking.

====Description du projet====

Nous disposons d'un drone Phantom3 d'1,2 Kg capable de supporter une charge utile d'1Kg. Nous devons utiliser cette charge utile à bon escient afin de ne pas perdre en autonomie. Nous envisageons donc d'utiliser environ 500g de matériel à monter sur le drone. Le système final doit remplir les fonctions suivantes :

* L'utilisateur devra pouvoir choisir sa destination via une interface portable soit par Bluetooth entre un téléphone mobile sur lequel sera préalablement installé une application soit par le biais d'une page internet hébergée sur une Raspberry.
* Le drone se déplacera à une hauteur conséquente et sera capable d'éviter et de contourner les obstacles présents sur son chemin.
* Le drone devra pouvoir se repérer automatiquement à l'extérieur.

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

Nous utiliserons probablement la plateforme ROS (Robot Operating System), qui nous permet d'utiliser différents modules (par exemple le SLAM). Nous aurons aussi recours à des bases de données, afin de recenser les utilisateurs, les salles, etc ; nécessitant alors une machine capable de les gérer via un logiciel du type MySQL.

[[Fichier:Dji3.jpg|400px|vignette|Alt=oui|Drone DJI Phantom3 Advanced ]]

Afin de réaliser notre projet, nous envisageons d'utiliser :

* un drone modèle Phantom3, fourni par Polytech Lille, cœur de notre projet ;

* une carte Raspberry, sur laquelle l'utilisateur pourra se connecter et accéder à la page d'accueil du drone ;

* un GPS, déjà intégré au drone, pour le localiser en permanence ;

* un écran LCD, que nous monterons sur le drone afin de faciliter l'utilisation du drone par le visiteur ;

* un module Wi-Fi ESP8266, afin de créer un serveur ouvert à tous ;

* un jeu de capteurs de proximité (Ultrasons/Infrarouge), afin de garantir l'intégrité physique du personnel et matérielle du drone.

 
 
 
 
 
 
 
 
 
 

===Calendrier prévisionnel===

====Liste des tâches à effectuer====

* Préliminaires :
** Étude du mode de communication entre le drone et l'application qui lui est dédiée.
** Étude de ROS (Robot Operating System) et des algorithmes de SLAM pour voir si ces composants logiciels peuvent faciliter le développement du projet.
** Installation de ROS sur RaspberryPi.

* Partie 1 :
** Installation du SDK de DJI.
** Essais sur les capteurs de proximité qui seront couplés à la RaspberryPi.
** Gestion d'un itinéraire par le drone, plus précisément la gestion d'un vol automatique avec le Phantom3.
** Communication drone/capteur par le biais de la carte RaspberryPi.
** Identification d'une personne grâce à une connexion Bluetooth entre un visiteur et la Raspberry.
** Mener une voiture à sa place de parking grâce aux éléments travaillés précédemment.

* Partie 2 :
** Se repérer dans Polytech grâce à un algorithme de SLAM intégré à la Raspberry.
** Se rendre dans une salle donnée en partant de l'entrée de Polytech. (coté parking)

<gallery>
Fichier:Gantt_partie_1.png| Gantt P31 partie 1 (''Cliquez pour agrandir'')
Fichier:Gantt_partie_2.png| Gantt P31 partie 2 (''Cliquez pour agrandir'')
Fichier:Gantt_partie_3.png| Gantt P31 partie 3 (''Cliquez pour agrandir'')
</gallery>

==Feuille d'heures==

{| class="wikitable"
!Tâche !! Prélude !! Heures S1 !! Heures S2 !! Heures S3 !! Heures S4 !! Heures S5 !! Heures S6 !! Heures S7 !! Heures S8 !! Heures S9 !! Heures S10 !! Total
|-
| Définition cahier des charges
| 2h
|
|
|
|
|
|
|
|
|
|
|
|-
| Installation du SDK DJI et de Android Studio, téléchargement de tous les packages manquants
|
|
| 4h
|
|
|
|
|
|
|
|
|
|-
| Etude des différents moyens de communication avec le drone
|
| 4h
|
|
|
|
|
|
|
|
|
|
|-
| Etude des capteurs via arduino
|
|
|
|
|
|
| 3h
|
|
|
|
|
|}

==Avancement du Projet==

===Semaine 1===

*Correction du cahier des charges.
 
*Établissement de la liste du matériel nécessaire à la réalisation de notre projet.
Pour ce projet, nous pensons qu'il serait en effet judicieux d'acheter du matériel supplémentaire afin de mener à bien notre projet. Il serait question d'utiliser:

* Carte RaspberryPi 3. Ce modèle est équipé d'un module bluetooth afin d'assurer la communication entre l'utilisateur et le drone, ainsi qu'entre le drone et les capteurs.

* 3 Capteurs de mesure Sharp GP2Y0A02YK. (référence : [http://www.gotronic.fr/art-capteur-de-mesure-sharp-gp2y0a02yk-11536.htm]). Nous avons choisi ce capteur sur 2 critères: Le prix et la plage de détection. En effet, il nous fallait un capteur de proximité ayant une plage de détection maximale entre 1 et 2 mètres afin que le drone puisse détecter les obstacles assez tôt pour pouvoir les éviter.

*Appareil mobile sous OS Android (portable ou tablette ). Cet appareil mobile pourra nous servir à installer les applications qui gérerons le drone. C'est également sur ce téléphone que sera gérer la base de données des itinéraires nécessaires aux déplacement du drone jusque à une place de parking.
 
[[Fichier:Djimode.jpg|right|400px|vignette|Alt=oui|Exemple du mode POI de DJI.]]
 
*Étude des différents modes de fonctionnement du drone (Point Of Interest, Homelock, etc).

 
Le mode POI présenté ci-contre pourrait par exemple être utilisé dans le cas où le drone serait arrivé à sa destination. Il attendrait en vol que la voiture se soit garé à sa place.
Nous pourrions également définir les places de parking comme des "homes" que le drone rejoindrait en suivant un itinéraire pré-défini et où il attendrait que la voiture arrive.
 
*Première découverte de ROS pour l'installer sur RaspberryPi.

Robot Operating System (ROS) est une plateforme de développement logicielle pour utilisée en robotique.[http://www.ros.org/]. Il s'agit d'un pseudo OS qui peut fonctionner sur ordinateur. ROS a pour intérêt d'offrir des fonctionnalités telles abstraction du matériel, le contrôle des périphériques de bas niveau, mise en œuvre de fonctionnalités couramment utilisées ainsi que la transmission de messages entre les processus.
 
La communication entre les processus s'opère de la façon suivante:
[[Fichier:ROScom.png|center|400px]]

Un premier node avertit le master qu'il a une donnée à partager. -> Un deuxième node avertit le master qu'il souhaite avoir accès à une donnée. 
Une connexion entre les deux nodes est créée. -> Le premier node peut envoyer des données au second.

L'implémentation d'un OS ROS sur une RaspberryPi pourrait donc être une bonne idée qu'il faudrait continuer à creuser afin de faire communiquer la Raspberry et le drone.

===Semaine 2===
*Approfondissement de l'étude du drone phantom3 de DJI.
*Suite à des problèmes au niveau de la communication avec le drone, une solution alternative est envisagée. Il s'agirait de concevoir nous même notre propre drone.
*Préparation d'un argumentaire à présenter aux encadrants du projet.

===Semaine 3===
*Nous envisageons désormais de créer une application permettant de communiquer avec le drone. Nous faisons donc des recherches autour de l'API du drone.
*Découverte du SDK (Software Development Kit ) proposé par le site "DJI-developper" qui permet de créer des applications pouvant communiquer avec notre drone.
*Installation de Android studio, application nécessaire à la création des applications via le SDK de DJI-developper.

===Semaine 4===
*Installation du SDK de DJI-developper sur notre ordinateur portable.

===Semaine 5===
*Nous tentons de créer une application Android permettant de diriger le drone Phantom3 en pointant au doigt sur un appareil mobile un emplacement sur une carte virtuelle. L'application est développée via Android Studio, et son code nous est fourni par le site DJI-developper (https://developer.dji.com/mobile-sdk/documentation/android-tutorials/GSDemo-Google-Map.html), site regroupant un ensemble non négligeable de codes exemple, dont celui que nous utilisons ici.

===Semaine 6===
*Lors de cette semaine nous rencontrons de nombreux problèmes avec le drone. En effet, il nous est impossible de faire démarrer les moteurs.Nous sommes donc dans l'impossibilité de tester l'application que nous venons terminer de coder. Nous nous lançons donc dans une phase de recherche au travers du manuel d'utilisation et d'internet afin de debugger notre drone. Après quelques recherches, nous pensons que le firmware de la télécommande ou du drone a besoin d'être updaté. Nous mettons donc à jour le drone. Le problème est que nous n'arrivons plus à faire communiquer l'API avec le drone car nous sommes constamment "déconnectés" malgré que le câble soit relié entre notre téléphone et le drone. Or, pour mettre à jour notre drone, nous devons avoir touts les éléments connectés.
*En parallèle, nous avons reçu nos capteurs de proximité. Nous décidons donc de commencer la partie communication capteur-Raspberry. Nous rencontrons de nouveau des problèmes, en effet nous n'arrivons pas à communiquer avec la Raspberry via la liaison série. La solution est de mettre dans le fichier "config.txt" de la partition /boot une ligne de commande < enable_uart = 1 > et < core_freq = 250 > afin de lancer dès le démarrage de la Raspberry la liaison série qui n'est plus lancée par défaut sur les Raspberry Pi 3.

===Semaine 7===
*Premier vols avec le drone. Nous le testons dehors en volant tout d'abord en mode manuel, c'est-à-dire en utilisant la télécommande fournie. Après nous être familiarisé avec le drone et ses déplacements, nous essayons maintenant de le faire voler en utilisant notre application. Cette application est installée sur un téléphone portable sous Android, de plus, ce téléphone est connecté par liaison filaire avec la télécommande afin d'assurer la communication entre le drone et le téléphone.
 
[[Fichier:cartedjigo.png||vignette|Alt=oui||left| Interface de l'application ]]

 
 
 
Cette application permet entre autre :
* De localiser le drone sur la carte mondiale tirée de Google Map. Une fois localisé, le drone est symbolisé par un avion sur la carte.
* De définir des paramètres de vols du drone tels que l'altitude de vol ou la vitesse de vol.
* De créer des "Waypoints", ou "points d’intérêt. Ces points sont définis par l’utilisateur en cliquant sur l'écran tactile du téléphone. Il peut définir autant de points qu'il désire. Lorsque le drone décollera, il ira à chacun des points d'intérêt définis.
* Lorsque les Waypoints et les paramètres de vols sont définis, et une fois que la mission a bien été compilée en appuyant sur la touche "Prepare", l'utilisateur peut lancer la session de vol en appuyant sur "Start".
 
<gallery>
Fichier:MenuAppP31.png| Menu paramètres de l'application (''Cliquez pour agrandir'')
</gallery>

 
 
La vidéo suivante montre le résultat d'un plan de vol en 2 "Waypoints". L'altitude est définie à 5m et la vitesse de vol à "lent":
 
https://drive.google.com/open?id=0ByKP9w_p1fHAR09EVFozZjVvRlE

 
* En parallèle, nous entamons également le travail sur le capteur de proximité couplé à la raspberry. Après quelques recherches, nous trouvons le schéma de montage suivant que nous allons réutiliser:
[[Fichier:Rasp.PNG|center ]]
 
 

===Semaine 8===

* Nous continuons la configuration de la Raspberry Pi3 afin de pouvoir utiliser le GPIO et lire les valeurs reçues sur les pins. Pour cela, nous devons tout d'abord relier la carte avec le réseau afin de pouvoir installer des paquets. Pour cela nous écrivons dans le fichier /etc/dhcpcd.conf les lignes suivantes:
 
[[Fichier:StaticPI.png|center]]
 
Nous allons désormais installer le paquet "wiringPi". Ce wiringPi est un outil qui permet de contrôler les différentes broches du port GPIO. Il permet entre autre de visualiser les valeurs et les fonctions de chaque pin du gpio et de changer mode en entrée ou en sortie. Cet outil est donc bien utile pour configurer notre Raspberry.
 
[[Fichier:PinPi.png|center]]
 
Un problème apparaît directement lorsque nous regardons le tableau. En effet, la colonne 'V' du tableau indique que la valeur sur la pin est de 1. Or, cette valeur reste la même lorsque l'obstacle bouge. cela signifie qu'il y a un système de seuil dans la Raspberry qui fait qu'au delà d'une certaine valeur, le signal détecté est un 1 logique. Pour remédier à ce problème, nous utilisons donc un convertisseur Analogique-Digital.
 
 
[[Fichier:Sensor.jpg|200px]] 
Ce convertisseur sur 12-bits va nous permettre de convertir la valeur analogique du capteur de proximité et de l'envoyer à la Raspberry. De plus, ce convertisseur possède 4 entrées analogiques, ce qui est suffisant pour accueillir nos 3 capteurs de proximités.

 
Après avoir installé quelques librairies et installé python sur notre carte, nous entamons la création d'un programme qui lira la valeur du capteur 1 (branché sur l'entrée analogique 0 ) et l'affiche dans le terminal. Nous nous servons de quelques programmes exemple trouvés sur internet afin de nous aider. Le résultat est le suivant: 
[[Fichier:Pyth.png]]
[[Fichier:Capteur1.JPG|400px]]

* Cette semaine nous avons étudié plus en détails le corps du programme principal de l'application. Celui-ci contient une vingtaine de fonctions remplissant des tâches diverses et variées :
- Une fonction permettant d'ajouter un marqueur sur la carte du monde à l'endroit ou l'utilisateur clique,
- Une fonction permettant d'ouvrir un sous-menu pour fixer les caractéristiques du vol,
- Une fonction permettant de valider les waypoints (WP) indiqués par l'utilisateur et de préparer le plan de vol,
- Et plus d'une dizaine d'autres fonctions que nous ne détaillerons pas ici car leur utilité dans le cadre de ce projet est moindre.

L'objectif des prochaines séances et de réaliser à partir de ce code l'application finale qui nous permettra, via l'appui sur un UNIQUE bouton de l'écran, d'à la fois choisir une place, de créer le plan de vol, et de faire décoller le drone. Afin de réaliser cet objectif, nous avons utilisé la fonction "addWaypointMarker (?)" : cette fonction, initialement, permettait d'autoriser l'ajout de WP sur l'écran, puis un second appui sur cette même touche sauvegardait les marqueurs puis interdisait l'ajout de nouveaux WP (jusqu'au prochain appui sur ce bouton) ; dorénavant un appui sur ce bouton permet à la fois de créer automatiquement les WP associés au parcours jusqu'à une place libre, de créer le plan de vol, puis de faire démarrer le drone.

'''(Ajouter photo du code ici)'''

===Semaine 9===
*Cette semaine nous nous attaquons à la création d'un support pour nos capteurs. Le but de ce support est d'accueillir nos 3 capteurs, la Raspberry Pi3 ainsi que le convertisseur Analogique-Digital. Ce support dit être le plus léger possible et prendre le moins de place possible.
Nous utilisons donc du balza, une sorte de bois léger utilisé pour le modélisme pour fabriquer entre autre les maquettes d'avions:
 
 
[[Fichier:Nacelle.JPG|600px]]
 
 
Comme indiqué précédemment lors de la dernière semaine. La lecture de la valeur d'un capteur passe un programme Python. Il faut désormais lire la valeur des 2 autres capteurs pour les afficher.De nombreux exemples sont disponibles sur la toile et le langage Python est assez intuitif. Nous arrivons rapidement au code suivant: 
 
[[Fichier:Programme_Python.png|500px]] 
Il a tout d'abord fallu importer la librairie RPi.GPIO qui permet de gérer les entrées/sorties du GPIO de la raspberry. A partir de là, le programme est assez simple, la seule difficulté est de retrouver les bons code qui correspondent à un convertisseur ADS1015. Ici le programme affiche la valeur de chaque capteur ( droit, avant ou gauche ) et si celle ci est trop petite, affiche un message puis allume la LED de la breadboard. 
Une temporisation a été nécessaire afin d'apercevoir l'allumage de la LED et surtout afin d'éviter de surcharger le buffer. 
 
Le résultat retourné sur le terminal est le suivant: 
[[Fichier:NacelleFin.png|400px|center]]
 
En conclusion: 
* Nous disposons d'une nacelle de 300 grammes qui pourra être embarquée par le drone. Celle ci détecte un obstacle jusque à 1 mètre apparaissant dans un angle de 130° à l'avant du drone.
* L'utilisation d'une batterie externe a été privilégiée afin d'éviter une trop grosse perte d'autonomie du drone si la raspberry avait été alimenté par le drone (via un câble double micro-usb).
* Un problème est parfois rencontré lorsque nous lançons le programme à cause de la communication i2c entre l'ADC et la raspberry. Ce problème est soit dû à la non libération du canal de transmission à la fin du programme soit dû à des adresses mémoires "volatiles".
* Il faut maintenant chercher un moyen de faire communiquer cette nacelle avec le téléphone afin d'envoyer une commande de stop au drone. La communication bluetooth ne sera pas utilisée car sa portée est trop courte. Nous essayerons donc de communiquer par Wi-fi. Nous savons qu'il est possible de faire communiquer un téléphone et une raspberry. Nous allons donc désormais orienter nos recherches vers l'envoi d'une variable via Wi-fi.

== Fichiers Rendus ==

Fichier:MenuAppP31.png

2017-03-22T13:20:23Z

Eprofit : Menu de l'application P31 pour diriger automatiquement le drone

Menu de l'application P31 pour diriger automatiquement le drone

IMA4 2016/2017 P31

2017-03-20T14:09:29Z

Eprofit : /* Feuille d'heures */

IMA4 2016/2017 P31

2017-03-20T13:23:57Z

Eprofit : /* Choix techniques : matériel et logiciel */

IMA4 2016/2017 P31

2017-03-20T13:23:42Z

Eprofit : /* Choix techniques : matériel et logiciel */

IMA4 2016/2017 P31

2017-03-20T13:23:26Z

Eprofit : /* Choix techniques : matériel et logiciel */

IMA4 2016/2017 P31

2017-03-20T13:22:33Z

Eprofit : /* Choix techniques : matériel et logiciel */

IMA4 2016/2017 P31

2017-03-20T13:20:13Z

Eprofit : /* Calendrier */

Fichier:Cartedjigo.png

2017-03-20T13:14:34Z

Eprofit : Au lancement de l'application djigo

Au lancement de l'application djigo

Fichier:Carte.png

2017-03-20T13:13:51Z

Eprofit : a téléversé une nouvelle version de « Fichier:Carte.png » : Au lancement de l'application

IMA4 2016/2017 P31

2017-03-15T15:20:28Z

Eprofit : /* Calendrier */

Discussion:Projets IMA4 SC & SA 2016/2017

2017-03-08T15:48:16Z

Eprofit : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Mini-cahier des charges || Mi-parcours || Fin de parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Cahier des charges conforme à la discussion avec l'encadrant. Présentation propre avec un effort d'illustration. Pas de liste des tâches ou de calendrier prévisionnel. Quelques coquilles corrigées.
| 
| 
| 
| 
| 
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Cahier des charges succinct. Attention à la rédaction en français. Un effort d'illustration avec un schéma global. Une liste des tâches, sans chiffrage pour l'instant..
| 
| 
| 
| 
| 
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Cahier des charges assez précis. Pas trop de coquilles. Une liste des tâches un peu succincte. Réfléchissez bien à la structure du programme pour la mise à jour simplifiée des fiches sur l'application.
| 
| 
| 
| 
| 
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Cahier des charges précis. Forme très correcte. Une liste des tâches réfléchie. Il y a même un calendrier prévisionnel.
| 
| 
| 
| 
| 
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Cahier des charges très précis. De même pour la liste des tâches. L'utilisation de bioloïds ne semble pas justifiée. Pourquoi ne parlez-vous de capteurs que dans le cadre d'un seul des deux appareils ?
| 
| 
| 
| 
| 
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Pas mal de coquilles corrigées. Une certaine imprécision (confusion Arduino Mega et ATMEGA, flou dans la liste des tâches). Cela dit un cahier des charges et une liste des tâches sont présentés. Pensez aux problèmes de calibration du système et à la transmission des données vers un smartphone par exemple.
| 
| 
| 
| 
| 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Synthèse correcte de l'entretien avec l'encadrant. Le cahier des charges est correct mais moins précis que le sujet. Le découpage en tâche est un peu rapide : l'analyse des fichiers MIDI devrait être sous-découpée. Presque pas de coquilles.
| 
| 
| 
| 
| 
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Très bonne prise en main du sujet. Cahier des charges très précis. Liste des tâches bien détaillée. Orthographe irréprochable.
| 
| 
| 
| 
| 
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Une grande partie du cahier des charges est une copie du sujet. Définissez ce qu'est une Referee Box. D'un autre coté, le cahier des charges est précis. La liste des tâches est correcte. Cependant elle semble omettre la partie mécanique de la MPS ? Pas de coquilles.
| 
| 
| 
| 
| 
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Des imprécisions dans la transcription de la réunion avec l'encadrant. Voire des contre-sens. Le cahier des charges est assez complet. Pas de liste des tâches. Vous avez vraiment passé 3h sur la rédaction du cahier des charges ? (edit d'Alex : certainement pas)Une liste des tâches ajoutée.
| 
| 
| 
| 
| 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Le texte a été modifié pour être compréhensible mais le problème n'est pas là. Vous n'avez pas du tout transcrit les demandes de l'encadrant mais donné le sujet du projet de l'an passé. Cette année vous devez améliorer l'aspect esthétique des robots, construire le quatrième robot et améliorer la détection infra-rouge en utilisant le protocole utilisé par les télécommandes infra-rouges classiques. Vous n'avez pas, non plus, donné une liste précise des tâches à réaliser.Cahier des charges révisé avec l'encadrant. La listes des tâches à réaliser est à préciser.
| 
| 
| 
| 
| 
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| La restitution de la discussion avec l'encadrant est très correcte et le cahier des charge est précisément décrit. Par contre la liste des tâches à effectuer n'est pas dressée en commençant par l'étude des conditions à respecter pour lancer un tel ballon.
| 
| 
| 
| 
| 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Assimilation très correcte des demandes faites par les encadrants. Un cahier des charges précis. De même pour la liste des tâches. Un effort de présentation sans trop de coquilles. Cependant quelques erreurs relevées par M. Dhaussy, merci de corriger le CdC au vu des remarques transmises.
| 
| 
| 
| 
| 
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| Le cahier des charges est une recopie du sujet, avec des passages soulignés, certes. Une liste des tâches très précise mais uniquement orientée développement Web. Il manque toute la partie étude et utilisation des éco-systèmes d'isolation.Cahier des charges plus précis, vous pouvez vous lancer.
| 
| 
| 
| 
| 
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Cahier des charges très précis avec déjà des idées pour la réalisation. Liste des tâches à effectuer très détaillée.
| 
| 
| 
| 
| 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Très peu d'apport par rapport au sujet qui est lui même assez bref. Il ne semble pas y avoir eu de rencontre avec l'encadrant dans les temps impartis ? Pas de liste des tâches. Cahier des charges révisés sous la direction de deux encadrants.
| 
| 
| 
| 
| 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Le cahier des charges est une paraphrase du sujet. Dans la liste des tâches il semble curieux de ne pas commencer par l'étude des brouilleurs. Avez-vous échangé avec vos encadrants ?Cahier des charges plus précis.
| 
| 
| 
| 
| 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Une simple paraphrase du sujet. Pas de liste des tâches à réaliser. Il semble que vous n'avez pas réussi à échanger avec vos encadrants dans les temps impartis. Des coquilles (corrigées).
| 
| 
| 
| 
| 
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Une rencontre avec les encadrants. Un cahier des charges assez précis. Pas de section "tâches à réaliser" mais une section "notre travail" qui pourrait en tenir lieu avec un effort de structuration.
| 
| 
| 
| 
| 
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Présentez les objectifs généraux pour commencer. Un cahier des charges très précis mais il manque la liste des tâches à effectuer. Débutez la par l'état de l'art sur les produits déjà commercialisés.
| 
| 
| 
| 
| 
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Le sujet du projet à été recopié. Les deux sections personnelles sont assez mal rédigées. Un contre-sens sur le mode de connexion du prototype actuel : la veilleuse est configurée en point d'accès. Parlez plutôt de "Précisions sur le cahier des charges" plutôt que de "Problèmes rencontrés sur l'étude du projet". Renommez aussi "Nouveau cahier des charges" en "Tâches à réaliser" et ajouter les autres tâches demandées dans le sujet.Cahier des charges et listes des tâches finalement validés par deux encadrants.
| 
| 
| 
| 
| 
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Uniquement une recopie du sujet.Un cahier des charges et une liste de tâches corrects après discussion avec deux encadrants.
| 
| 
| 
| 
| 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Un très bon cahier des charges. Le sujet semble être bien assimilé. Une liste des tâches correcte (il faudrait peut-être détailler la programmation du proxy).
| 
| 
| 
| 
| 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Un excellent cahier des charges. Liste des tâches très détaillée. Parfait.
| 
| 
| 
| 
| 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Vous n'avez pas su vous adapter à la syntaxe mediawiki. Correction pour obtenir un CdC lisible. Une recopie intégrale du sujet. Un cahier des charges qui ressemble plus à une liste des tâches à effectuer.Vous utilisez bien la syntaxe mediawiki maintenant. Par contre il n'y a toujours pas de cahier des charges.
| 
| 
| 
| 
| 
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Un cahier des charges en 4 lignes, c'est trop court. En particulier rien sur le contexte du projet à savoir le matériel ou le simulateur sur lequel les tests seront effectués. Une liste des tâches, cette liste est-elle avalisé par l'encadrant ?Toujours pas de cahier des charges.
| 
| 
| 
| 
| 
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (25/01) !! Séance 2 (01/02) !! Séance 3 (08/02) !! Séance 4 (15/02) !! Séance 5 (01/03) !! Séance 6 (08/03) !! Séance 7 !! Séance 8 !! Séance 9 !! Séance 10
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Haroun Abdelali
| 
| Absent
| Absent
| D317 
| D309 
| D309 
| 
| 
| 
| 
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Wenyu sun / Xinyue xu
| E304 Presentes
| C201 Présentes
| C201Présentes
| C201Présentes
| E304&C201
| E304
| 
| 
| 
| 
| 
| 
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Martin Rohmer / Kévin Godesence
| E306 
| E303 Présents
| E301 Présents
| E305
| E303
| E305
| 
| 
| 
| 
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Robin Cavalieri / Edmur Lopes
| E305 
| E305 Présents
| E305Présents
| E305
| E305
| E305
| 
| 
| 
| 
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Cedric Roussel / Thomas Stievenard
| 
| E303 Présents
| Présents
| E305
| E303
| E305
| 
| 
| 
| 
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Mame Arame Diop / Amina Fahem
| 
| E303 Présentes
| E304 Présents
| E304
| E304
| E304
| 
| 
| 
| 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Antoine Arnaudet / Vivian Senaffe
| E304 
| E305 Arnaudet présent Senaffe absent
| E304
| E304Présents
| E304
| E304
| 
| 
| 
| 
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Butaye Marianne / François Duport
| E304 
| E304 Présents
| E303 Présents
| E305
| E305
| E305
| 
| 
| 
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Samy Belhouachi / François Xavier Cockenpot
| 
| E305 Présents
| E301 Présents
| E305 
| E303 et E305
| E303 et E305
| 
| 
| 
| 
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Cheikh Said Ahmed / Khadija El Messnaoui
| 
| E305 Said-Ahmed présent El Messnaoui absente
| Présents
| E303 
| E305
| 
| 
| 
| 
| 
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Manlu Luo / Xinyi Wang
| E305 
| E304 Présentes
| E304 Présentes
| E304 
| E304 
| 
| 
| 
| 
| 
| 
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| Olivier Mahieux / Grillère Baptiste
| E306 
| E305 Présents
| Présents
| 
| 
| 
| 
| 
| 
| 
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Rodolphe Toin
| E305 
| E305 Présent
| E305/301 Présents
| E305 
| E305 
| E305 
| 
| 
| 
| 
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| | E304 
| Rattrapage DS
| Abs
| Malade
| Malade
| Malade
| E303
| 
| 
| 
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Thomas Gosse / Bacem Hagui
| 
| E304 Gosse présent Hagui absent
| Présents
| 
| 
| 
| 
| 
| 
| 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Tristan Hart / Etienne Profit
| 
| E304 Présents
| E304Présents
| E304
| E304
| E304
| E304
| 
| 
| 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Nicky Ung / Alexis Macherez
| E304 
| E304 Présents
| E304/301 Présents
| E305
| E304
| 
| 
| 
| 
| 
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Oumaima Naanaa
| 
| Absente
| E301Présente
| E301
| E301
| 
| 
| 
| 
| 
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Alice Coffin / Diana Marrucho
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
| IRCICA labo
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Lutecia Damiens / Alexis Dorian
| E306 
| E303 Présents
| E303 Présents
| Fabricarium
| E303
| E306
| 
| 
| 
| 
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Hugo Delatte
| 
| E304 Présents
| E304 
| E304 Présents
| 
| 
| 
| 
| 
| 
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Loïc Tombazzi / Marius Trimbur
| E304 
| E303 Présents
| E303 Présents
| E304 
| E303
| 
| 
| 
| 
| 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Marouan Mcharfi / Tristan lopez
| E304 
| E304 Présents
| E304 Présents
| E304 
| E304
| 
| 
| 
| 
| 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Alexandre Huet / François Lefevre
| E306
| E306 Présents
| E304 Présents
| 
| 
| 
| 
| 
| 
| 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Djamil Mohamed / Hamza Kerroum
| C305/D306A 
| C305/D306A Présents
| C305/D306A Présents
| C305/D306A 
| C305/D306A 
| C305/D306A
| 
| 
| 
| 
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Jean-Baptiste Saison
| C305/D306A 
| C305/D306A Présent
| D306A Présent
| D306A/C305 
| D306A/D322 
| D306A/D322 
| 
| 
| 
| 
|}

Discussion:IMA4 2016/2017 P31

2017-03-08T15:35:47Z

Eprofit :

* 25 Janvier 2017 : E304 Zabeth04
* 1er Février 2017 : E304 Zabeth04
* 8 Février 2017 : E305 Astruc11
* 15 Février 2017 : E305 Astruc11
* 1er Mars 2017 : E305 Astruc11
* 8 Mars 2017 : E305 Astruc11

Discussion:IMA4 2016/2017 P31

2017-03-01T13:13:44Z

Eprofit :

* 25 Janvier 2017 : E304 Zabeth04
* 1er Février 2017 : E304 Zabeth04
* 8 Février 2017 : E305 Astruc11
* 15 Février 2017 : E305 Astruc11
* 1er Mars 2017 : E305 Astruc11

IMA4 2016/2017 P31

2017-03-01T13:10:22Z

Eprofit : /* Avancement du Projet */

IMA4 2016/2017 P31

2017-03-01T13:02:56Z

Eprofit : /* Feuille d'heures */

IMA4 2016/2017 P31

2017-03-01T13:02:37Z

Eprofit : /* Feuille d'heures */

Discussion:IMA4 2016/2017 P31

2017-02-08T12:33:15Z

Eprofit :

* 25 Janvier 2017 : E304 Zabeth04
* 1er Février 2017 : E304 Zabeth04
* 8 Février 2017 : E305 Astruc

Projets IMA4 SC & SA 2016/2017

2017-02-01T13:56:43Z

Eprofit : /* Matériel à acquérir */

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
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Xavier Redon
| Haroun Abdelali
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Wenyu sun / Xinyue xu
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Fanny Moreau / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Martin Rohmer / Kévin Godesence
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Marion Binninger / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Robin Cavalieri / Edmur Lopes
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Alexandre Boé / Xavier Redon
| Cedric Roussel / Thomas Stievenard
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Rodolphe Astori / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Mame Arame Diop / Amina Fahem
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Lucas Prieux / Hidéo Vinot / Xavier Redon / Thomas Vantroys
| Antoine Arnaudet / Vivian Senaffe
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Rochdi Merzouki / Vincent Coelen / Valentin Vergez
| Butaye Marianne / François Duport
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Rochdi Merzouki / Thomas Danel / Valentin Vergez
| Samy Belhouachi / François Xavier Cockenpot
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Xavier Redon / Alexandre Boé
| Cheikh Said Ahmed / Khadija El Messnaoui
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Xavier Redon / Alexandre Boé
| Manlu Luo / Xinyi Wang
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| Xavier Redon / Thomas Vantroys / Alexandre Boé
| Olivier Mahieux / Grillère Baptiste
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Xavier Redon / Gilles Dhaussy
| Rodolphe Toin
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| Xavier Redon / Thomas Vantroys
| Jade Dupont (valentin)
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Thomas Gosse / Bacem Hagui
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Tristan Hart / Etienne Profit
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Nicky Ung / Alexis Macherez
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Oumaima Naanaa
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Betty Semail / Laurent Grisoni / Frédéric Giraud
| Alice Coffin / Diana Marrucho
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Alexandre Boé / Thomas Vantroys / Xavier Redon
| Lutecia Damiens / Alexis Dorian
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Thomas Vantroys / Alexandre Boé
| Hugo Delatte
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Loïc Tombazzi / Marius Trimbur
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Thomas Vantroys
| Marouan Mcharfi / Tristan Lopez
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Alexandre Huet / François Lefevre
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Midzodzi Pekpe
| Djamil Mohammed / Hamza Kerroum
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Midzodzi Pekpe
| Jean-Baptiste Saison
|}

== Matériel à acquérir ==

{| class="wikitable"
! Projet !! Matériel
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
|
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
|
 Capteur de température, Mouser[http://www.mouser.fr/ProductDetail/Microchip-Technology/TC1047VNBTR/?qs=sGAEpiMZZMucenltShoSnjkfRJmEyKRQimeb4yJa%2fn8%3d], 
Smartphone sous Android, 
bread board, 
USB fils[http://www.gotronic.fr/art-cordon-1-8m-cw091b-15249.htm], 
ATmega32u4, [http://www.microchipdirect.com/ProductDetails.aspx?Category=ATmega32U4], 
Connecteur USB-A[http://fr.rs-online.com/web/p/connecteurs-usb-type-a/6741325/], 
quartz 16Mhz 

|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
|
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
|
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
|
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
|
Accéléromètre (4 à 5) ADXL335[http://www.gotronic.fr/art-module-accelerometre-adxl335-3-axes-ef03049-23504.htm], 
Smartphone sous Android, 
15 longs fils male femelle , 
Arduino Mega, 
Résistance , 
Module WIFI ESP 8266 [http://www.gotronic.fr/art-module-wifi-serie-esp8266-113990084-23666.htm] 
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
|
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
|
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
|
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
|
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
|
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
|
Capteur de température DS75LV maximintegrated (Disponible en free sample) 
Capteur de pression [http://www.mouser.com/ds/2/418/NG_DS_MS5525DSO_C1-786470.pdf] 
Accéléromètre ADXL345 [http://www.analog.com/media/en/technical-documentation/data-sheets/ADXL345.pdf] 
Module LoRa pour RaspberryPi [http://snootlab.com/shields-snootlab/1152-chistera-pi-12-lora-accessoires-fr.html] 
Module de réception LoRa terrestre : SX1272 development kit [http://www.lextronic.fr/P37768-module-radio-oem-arm-n8-lorawan.html] 
Module GPS [http://www.mouser.com/ds/2/389/sta8088exg-974189.pdf] 
1 RaspberryPi
|
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
|
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
|
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
|
 Accéléromètre ADXL335 , 
 Arduino Nano , 
 2x Module XBee + 1x Shield , 
 Arduino UNO , 
 Xbee Adapter Board, 
 Raspberry Pi, 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
|
Carte RaspberryPi (Au minimum modèle 2), 
Alimentation MicroUSB pour RaspberryPi, 
Carte MicroSD 16Gb, 
Dongle Bluetooth BLED112-V1[http://fr.rs-online.com/web/p/adaptateurs-bluetooth/8077742/], 
Capteur de mesure Sharp GP2Y0A02YK x3 [http://www.gotronic.fr/art-capteur-de-mesure-sharp-gp2y0a02yk-11536.htm], 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
|
Carte Arduino, 
Emetteur RF (868MHz, ASK,FSK ou OOK), 
Récepteur LoRa(868MHz), 
2 antennes, 
Batterie, 
Quelques LEDs
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
|
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
|
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
|
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
|
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
|
Deux lasers de différentes couleurs, 
Une paire de galvanomètres à miroir, 
Arduino, 
Raspberry Pi3, 
Câble secteur, 
Drivers galvanomètres x2, 
Alimentation laser, 
Lunette de sécurité x2 [https://www.amazon.fr/Uvex-S1933X-Eyewear-SCTOrange-Anti-Fog/dp/B000USRG90/ref=sr_1_1?ie=UTF8&qid=1485441383&sr=8-1&keywords=uvex+s1933x], 
Alimentation 230V/5V 1A [http://www.miniinthebox.com/fr/dual-usb-eu-prise-murale-5v-2a-voyage-adaptateur-chargeur-d-alimentation-pour-iphone7-6-xiaomi-samsung-et-autre-telephone-portable_p5410410.html?currency=EUR&litb_from=paid_adwords_shopping&sku=429_6917%7C752_20648&utm_source=google_shopping&utm_medium=cpc&adword_mt=&adword_ct=138705676724&adword_kw=&adword_pos=1o5&adword_pl=&adword_net=g&adword_tar=&adw_src_id=9653316068_661261352_33588296076_aud-79897721311:pla-256966386459&gclid=Cj0KEQiA_KvEBRCtzNil4-KR-LIBEiQAmgekFxxKjJJWBYCJlDZEa3Ke_2_WR0DzGVbz-jaCZHVIBoMaAvld8P8HAQ], 
Boitier ABS [http://fr.farnell.com/multicomp/g3118/boitier-abs-240x120x60mm-ip65/dp/1526656], 
DAC 4 canaux, avec interface I²C [http://www.mouser.fr/ProductDetail/Adafruit/1083/?qs=sGAEpiMZZMsMyYRRhGMFNtB2KhoPg%2fPbP3CExTYfM4M%3d], 
Connecteur C14 [http://www.conrad.fr/ce/fr/product/715001/Connecteur-secteur-C14-Embase-male-verticale-715001-Nombre-de-poles-2-PE-10-A-noir-1-pcs/?ref=detview1&rt=detview1&rb=1], 
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
|
Un Minitel 1 Bistandard Alcatel Telic, 
un connecteur DIN 5 broches[http://www.selectronic.fr/din-cordon-male-5-broches-45.html], 
un Arduino Uno [http://www.selectronic.fr/carte-arduino-uno.html], 
un module Ethernet [http://www.selectronic.fr/shield-ethernet-v2.html]. 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
|
Rfduino DIP board + USB shield, Mouser [http://eu.mouser.com/ProductDetail/RF-Digital-Wireless/RFD90101/?qs=sGAEpiMZZMsrChSOYEGTCSSoddgmKGJ7o1oPrqG%2fa%2fU%3d], 
Rfduino Dual AAA shield, Mouser [http://eu.mouser.com/ProductDetail/RF-Digital-Wireless/RFD22126/?qs=sGAEpiMZZMsrChSOYEGTCTCnakKeCOV7XxQSzqVKQX4%3d], 
Raspberry Pi, 
Clef wifi, 
2 piles de 1,5V AAA , 
1 buzzer, Mouser [http://www.mouser.fr/ProductDetail/TDK/PS1240P02BT/?qs=sGAEpiMZZMtWZVZ%2fjgUYS49cTVUJP3OaWyx1fxdmA7I%3d] , 
1 accéléromètre, mouser [http://www.mouser.fr/ProductDetail/NXP-Freescale/MMA8653FCR1/?qs=sGAEpiMZZMs0JOhy9PM0USp5vOY2ClxOY1G2fK3tzYI%3d] , 
3 LEDs de couleurs différentes, 2 Mouser Rouge[http://www.mouser.fr/ProductDetail/Lumex/SSL-LX5093LBI-SRD/?qs=sGAEpiMZZMvHYEB9WUp7ElLqM0HAvqw07NtkT0umwJ8%3d], Mouser Vert [http://www.mouser.fr/ProductDetail/Dialight/521-9465F/?qs=sGAEpiMZZMvHYEB9WUp7EvzO6BrrarQchHylkK4n3ZA%3d], , 
Smartphone sous Android, 
Aimants, Farnell [http://fr.farnell.com/duratool/d01767/aimant-12-x-3mm-pqt6/dp/1888096], 
3 Résistances CMS 330 Ohms, Mouser [http://www.mouser.fr/ProductDetail/Vishay/CRCW1206330RFKEA/?qs=sGAEpiMZZMvdGkrng054t%252b8cnVAnHPZkGMXtw0W%2fcW8%3d] 
1 Résistance CMS 10 kOhms, Mouser [http://www.mouser.fr/ProductDetail/Vishay/CRCW120610K0FKEA/?qs=sGAEpiMZZMvdGkrng054txEw7b1YnvGuaUb8csQljuk%3d] 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
|
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
|
|}

Discussion:IMA4 2016/2017 P31

2017-02-01T13:48:19Z

Eprofit : Page créée avec « 25 Janvier 2017 : E304 Zabeth04 1er Février 2017 : E304 Zabeth04 »

25 Janvier 2017 : E304 Zabeth04
1er Février 2017 : E304 Zabeth04

IMA4 2016/2017 P31

2017-01-25T16:40:21Z

Eprofit : /* Semaine 1 */

IMA4 2016/2017 P31

2017-01-25T16:36:42Z

Eprofit : /* Feuille d'heures */

Projets IMA4 SC & SA 2016/2017

2017-01-25T15:30:23Z

Eprofit : /* Matériel à acquérir */

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
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Xavier Redon
| Haroun Abdelali
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Wenyu sun / Xinyue xu
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Fanny Moreau / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Martin Rohmer / Kévin Godesence
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Marion Binninger / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Robin Cavalieri / Edmur Lopes
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Alexandre Boé / Xavier Redon
| Cedric Roussel / Thomas Stievenard
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Rodolphe Astori / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Mame Arame Diop / Amina Fahem
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Lucas Prieux / Hidéo Vinot / Xavier Redon / Thomas Vantroys
| Antoine Arnaudet / Vivian Senaffe
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Rochdi Merzouki / Vincent Coelen / Valentin Vergez
| Butaye Marianne / François Duport
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Rochdi Merzouki / Thomas Danel / Valentin Vergez
| Samy Belhouachi / François Xavier Cockenpot
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Xavier Redon / Alexandre Boé
| Cheikh Said Ahmed / Khadija El Messnaoui
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Xavier Redon / Alexandre Boé
| Manlu Luo / Xinyi Wang
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| Xavier Redon / Thomas Vantroys / Alexandre Boé
| Olivier Mahieux / Grillère Baptiste
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Xavier Redon / Gilles Dhaussy
| Rodolphe Toin
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| Xavier Redon / Thomas Vantroys
| Jade Dupont (valentin)
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Thomas Gosse / Bacem Hagui
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Tristan Hart / Etienne Profit
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Nicky Ung / Alexis Macherez
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Oumaima Naanaa
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Betty Semail / Laurent Grisoni / Frédéric Giraud
| Alice Coffin / Diana Marrucho
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Alexandre Boé / Thomas Vantroys / Xavier Redon
| Lutecia Damiens / Alexis Dorian
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Thomas Vantroys / Alexandre Boé
| Hugo Delatte
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Loïc Tombazzi / Marius Trimbur
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Thomas Vantroys
| Marouan Mcharfi / Tristan Lopez
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Alexandre Huet / François Lefevre
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Midzodzi Pekpe
| Djamil Mohammed / Hamza Kerroum
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Midzodzi Pekpe
| Jean-Baptiste Saison
|}

== Matériel à acquérir ==

{| class="wikitable"
! Projet !! Matériel
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
|
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
|
 Capteur de température, Mouser[http://www.mouser.fr/ProductDetail/Microchip-Technology/TC1047VNBTR/?qs=sGAEpiMZZMucenltShoSnjkfRJmEyKRQimeb4yJa%2fn8%3d], 
Smartphone sous Adroid, 
bread board, 
USB fils[http://www.gotronic.fr/art-cordon-1-8m-cw091b-15249.htm], 
ATmega32u4, [http://www.microchipdirect.com/ProductDetails.aspx?Category=ATmega32U4], 
Connecteur USB-A[http://fr.rs-online.com/web/p/connecteurs-usb-type-a/6741325/], 

|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
|
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
|
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
|
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
|
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
|
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
|
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
|
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
|
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
|
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
|
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
|
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
|
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
|
 Accéléromètre ADXL335 , 
 Arduino Mini : reçu , 
 2x Module XBee , 
 Adaptateur mini-USB Arduino Mini :reçu , 
 Xbee Adapter Board : reçu , 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
|
Carte RaspberryPi (Au minimum modèle 2), 
Alimentation MicroUSB pour RaspberryPi, 
Carte MicroSD 16Gb, 
Dongle Bluetooth BLED112-V1[http://fr.rs-online.com/web/p/adaptateurs-bluetooth/8077742/], 
Capteur de mesure Sharp GP2Y0A02YK x3 [http://www.gotronic.fr/art-capteur-de-mesure-sharp-gp2y0a02yk-11536.htm], 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
|
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
|
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
|
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
|
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
|
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
|
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
|
Un Minitel 1 Bistandard Alcatel Telic, 
un connecteur DIN 5 broches[http://www.selectronic.fr/din-cordon-male-5-broches-45.html], 
un Arduino Uno [http://www.selectronic.fr/carte-arduino-uno.html], 
un module Ethernet [http://www.selectronic.fr/shield-ethernet-v2.html]. 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
|
Rfduino DIP board + USB shield, Mouser [http://eu.mouser.com/ProductDetail/RF-Digital-Wireless/RFD90101/?qs=sGAEpiMZZMsrChSOYEGTCSSoddgmKGJ7o1oPrqG%2fa%2fU%3d], 
Rfduino Dual AAA shield, Mouser [http://eu.mouser.com/ProductDetail/RF-Digital-Wireless/RFD22126/?qs=sGAEpiMZZMsrChSOYEGTCTCnakKeCOV7XxQSzqVKQX4%3d], 
Raspberry Pi, 
Clef wifi, 
2 piles de 1,5V AAA , 
Petite BreadBoard, 
1 buzzer, Mouser [http://www.mouser.fr/ProductDetail/TDK/PS1240P02BT/?qs=sGAEpiMZZMtWZVZ%2fjgUYS49cTVUJP3OaWyx1fxdmA7I%3d] , 
1 accéléromètre, mouser [http://www.mouser.fr/ProductDetail/NXP-Freescale/MMA8653FCR1/?qs=sGAEpiMZZMs0JOhy9PM0USp5vOY2ClxOY1G2fK3tzYI%3d] , 
3 LEDs de couleurs différentes , 
Smartphone sous Android, 
3 Résistances CMS 330 Ohms, Mouser [http://www.mouser.fr/ProductDetail/Vishay/CRCW1206330RFKEA/?qs=sGAEpiMZZMvdGkrng054t%252b8cnVAnHPZkGMXtw0W%2fcW8%3d] 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
|
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
|
|}

Projets IMA4 SC & SA 2016/2017

2017-01-25T15:29:33Z

Eprofit : /* Matériel à acquérir */

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
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Xavier Redon
| Haroun Abdelali
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Wenyu sun / Xinyue xu
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Fanny Moreau / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Martin Rohmer / Kévin Godesence
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Marion Binninger / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Robin Cavalieri / Edmur Lopes
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Alexandre Boé / Xavier Redon
| Cedric Roussel / Thomas Stievenard
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Rodolphe Astori / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Mame Arame Diop / Amina Fahem
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Lucas Prieux / Hidéo Vinot / Xavier Redon / Thomas Vantroys
| Antoine Arnaudet / Vivian Senaffe
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Rochdi Merzouki / Vincent Coelen / Valentin Vergez
| Butaye Marianne / François Duport
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Rochdi Merzouki / Thomas Danel / Valentin Vergez
| Samy Belhouachi / François Xavier Cockenpot
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Xavier Redon / Alexandre Boé
| Cheikh Said Ahmed / Khadija El Messnaoui
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Xavier Redon / Alexandre Boé
| Manlu Luo / Xinyi Wang
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| Xavier Redon / Thomas Vantroys / Alexandre Boé
| Olivier Mahieux / Grillère Baptiste
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Xavier Redon / Gilles Dhaussy
| Rodolphe Toin
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| Xavier Redon / Thomas Vantroys
| Jade Dupont (valentin)
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Thomas Gosse / Bacem Hagui
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Tristan Hart / Etienne Profit
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Nicky Ung / Alexis Macherez
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Oumaima Naanaa
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Betty Semail / Laurent Grisoni / Frédéric Giraud
| Alice Coffin / Diana Marrucho
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Alexandre Boé / Thomas Vantroys / Xavier Redon
| Lutecia Damiens / Alexis Dorian
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Thomas Vantroys / Alexandre Boé
| Hugo Delatte
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Loïc Tombazzi / Marius Trimbur
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Thomas Vantroys
| Marouan Mcharfi / Tristan Lopez
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Alexandre Huet / François Lefevre
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Midzodzi Pekpe
| Djamil Mohammed / Hamza Kerroum
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Midzodzi Pekpe
| Jean-Baptiste Saison
|}

== Matériel à acquérir ==

{| class="wikitable"
! Projet !! Matériel
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
|
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
|
 Capteur de température, Mouser[http://www.mouser.fr/ProductDetail/Microchip-Technology/TC1047VNBTR/?qs=sGAEpiMZZMucenltShoSnjkfRJmEyKRQimeb4yJa%2fn8%3d], 
Smartphone sous Adroid, 
bread board, 
USB fils[http://www.gotronic.fr/art-cordon-1-8m-cw091b-15249.htm], 
ATmega32u4, [http://www.microchipdirect.com/ProductDetails.aspx?Category=ATmega32U4], 
Connecteur USB-A[http://fr.rs-online.com/web/p/connecteurs-usb-type-a/6741325/], 

|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
|
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
|
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
|
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
|
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
|
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
|
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
|
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
|
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
|
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
|
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
|
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
|
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
|
 Accéléromètre ADXL335 , 
 Arduino Mini : reçu , 
 2x Module XBee , 
 Adaptateur mini-USB Arduino Mini :reçu , 
 Xbee Adapter Board : reçu , 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
|
Carte RaspberryPi (Au minimum modèle 2), 
Carte MicroSD 16Gb, 
Dongle Bluetooth BLED112-V1[http://fr.rs-online.com/web/p/adaptateurs-bluetooth/8077742/], 
Capteur de mesure Sharp GP2Y0A02YK x3 [http://www.gotronic.fr/art-capteur-de-mesure-sharp-gp2y0a02yk-11536.htm], 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
|
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
|
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
|
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
|
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
|
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
|
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
|
Un Minitel 1 Bistandard Alcatel Telic, 
un connecteur DIN 5 broches[http://www.selectronic.fr/din-cordon-male-5-broches-45.html], 
un Arduino Uno [http://www.selectronic.fr/carte-arduino-uno.html], 
un module Ethernet [http://www.selectronic.fr/shield-ethernet-v2.html]. 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
|
Rfduino DIP board + USB shield, Mouser [http://eu.mouser.com/ProductDetail/RF-Digital-Wireless/RFD90101/?qs=sGAEpiMZZMsrChSOYEGTCSSoddgmKGJ7o1oPrqG%2fa%2fU%3d], 
Rfduino Dual AAA shield, Mouser [http://eu.mouser.com/ProductDetail/RF-Digital-Wireless/RFD22126/?qs=sGAEpiMZZMsrChSOYEGTCTCnakKeCOV7XxQSzqVKQX4%3d], 
Raspberry Pi, 
Clef wifi, 
2 piles de 1,5V AAA , 
Petite BreadBoard, 
1 buzzer, Mouser [http://www.mouser.fr/ProductDetail/TDK/PS1240P02BT/?qs=sGAEpiMZZMtWZVZ%2fjgUYS49cTVUJP3OaWyx1fxdmA7I%3d] , 
1 accéléromètre, mouser [http://www.mouser.fr/ProductDetail/NXP-Freescale/MMA8653FCR1/?qs=sGAEpiMZZMs0JOhy9PM0USp5vOY2ClxOY1G2fK3tzYI%3d] , 
3 LEDs de couleurs différentes , 
Smartphone sous Android, 
3 Résistances CMS 330 Ohms, Mouser [http://www.mouser.fr/ProductDetail/Vishay/CRCW1206330RFKEA/?qs=sGAEpiMZZMvdGkrng054t%252b8cnVAnHPZkGMXtw0W%2fcW8%3d] 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
|
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
|
|}

Projets IMA4 SC & SA 2016/2017

2017-01-25T15:23:57Z

Eprofit : /* Matériel à acquérir */

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
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
| Xavier Redon
| Haroun Abdelali
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Wenyu sun / Xinyue xu
|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
| Fanny Moreau / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Martin Rohmer / Kévin Godesence
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
| Marion Binninger / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Robin Cavalieri / Edmur Lopes
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
| Alexandre Boé / Xavier Redon
| Cedric Roussel / Thomas Stievenard
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
| Rodolphe Astori / Alexandre Boé / Xavier Redon / Thomas Vantroys
| Mame Arame Diop / Amina Fahem
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
| Lucas Prieux / Hidéo Vinot / Xavier Redon / Thomas Vantroys
| Antoine Arnaudet / Vivian Senaffe
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
| Rochdi Merzouki / Vincent Coelen / Valentin Vergez
| Butaye Marianne / François Duport
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
| Rochdi Merzouki / Thomas Danel / Valentin Vergez
| Samy Belhouachi / François Xavier Cockenpot
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
| Xavier Redon / Alexandre Boé
| Cheikh Said Ahmed / Khadija El Messnaoui
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
| Xavier Redon / Alexandre Boé
| Manlu Luo / Xinyi Wang
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
| Xavier Redon / Thomas Vantroys / Alexandre Boé
| Olivier Mahieux / Grillère Baptiste
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
| Xavier Redon / Gilles Dhaussy
| Rodolphe Toin
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
| Xavier Redon / Thomas Vantroys
| Jade Dupont (valentin)
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Thomas Gosse / Bacem Hagui
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Tristan Hart / Etienne Profit
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Nicky Ung / Alexis Macherez
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
| Thomas Vantroys / Alexandre Boé / Xavier Redon
| Oumaima Naanaa
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
| Betty Semail / Laurent Grisoni / Frédéric Giraud
| Alice Coffin / Diana Marrucho
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
| Alexandre Boé / Thomas Vantroys / Xavier Redon
| Lutecia Damiens / Alexis Dorian
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
| Thomas Vantroys / Alexandre Boé
| Hugo Delatte
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
| Xavier Redon / Alexandre Boé / Thomas Vantroys
| Loïc Tombazzi / Marius Trimbur
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
| Thomas Vantroys
| Marouan Mcharfi / Tristan Lopez
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
| Alexandre Boé / Xavier Redon / Thomas Vantroys
| Alexandre Huet / François Lefevre
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
| Midzodzi Pekpe
| Djamil Mohammed / Hamza Kerroum
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
| Midzodzi Pekpe
| Jean-Baptiste Saison
|}

== Matériel à acquérir ==

{| class="wikitable"
! Projet !! Matériel
|-
| P1 [[IMA4 2016/2017 P1|Climatisation du pauvre]]
|
|-
| P2 [[IMA4 2016/2017 P2|Réseau de capteurs sur smartphone]]
|
 Capteur de température, Mouser[http://www.mouser.fr/ProductDetail/Microchip-Technology/TC1047VNBTR/?qs=sGAEpiMZZMucenltShoSnjkfRJmEyKRQimeb4yJa%2fn8%3d], 
Smartphone sous Adroid, 
bread board, 
USB fils[http://www.gotronic.fr/art-cordon-1-8m-cw091b-15249.htm], 
ATmega32u4, [http://www.microchipdirect.com/ProductDetails.aspx?Category=ATmega32U4], 
Connecteur USB-A[http://fr.rs-online.com/web/p/connecteurs-usb-type-a/6741325/], 

|-
| P10 [[IMA4 2016/2017 P10|Application de suivi de prise de médicaments]]
|
|-
| P11 [[IMA4 2016/2017 P11|Amélioration de l'accueil d'enfants hospitalisés]]
|
|-
| P14 [[IMA4 2016/2017 P14|Sex toy connecté]]
|
|-
| P18 [[IMA4 2016/2017 P18|Education de la position de tête]]
|
|-
| P19 [[IMA4 2016/2017 P19|Orchestre électronique]]
|
|-
| P20 [[IMA4 2016/2017 P20|Création d’un environnement virtuel de test]]
|
|-
| P21 [[IMA4 2016/2017 P21|Conception d’une MPS Polyvalente]]
|
|-
| P25 [[IMA4 2016/2017 P25|Robot mobile Polytech'Lille]]
|
|-
| P26 [[IMA4 2016/2017 P26|Train de véhicules]]
|
|-
| P27 [[IMA4 2016/2017 P27|Sonde atmosphérique]]
|
|-
| P28 [[IMA4 2016/2017 P28|Adaptation d'un émulateur de calculatrices TI]]
|
|-
| P29 [[IMA4 2016/2017 P29|Conteneurs pour site Web]]
|
|-
| P30 [[IMA4 2016/2017 P30|Voiture radiocommandée controlée par gant]]
|
 Accéléromètre ADXL335 , 
 Arduino Mini : reçu , 
 2x Module XBee , 
 Adaptateur mini-USB Arduino Mini :reçu , 
 Xbee Adapter Board : reçu , 
|-
| P31 [[IMA4 2016/2017 P31|Accueil personnalisé par drone]]
|
Carte RaspberryPi (Au minimum modèle 2), 
Carte MicroSD 16Gb, 
Dongle Bluetooth BLED112-V1[http://fr.rs-online.com/web/p/adaptateurs-bluetooth/8077742/], 
|-
| P32 [[IMA4 2016/2017 P32|Sécurité: brouilleur d'ondes]]
|
|-
| P33 [[IMA4 2016/2017 P33|Sécurité: ingénierie inverse de protocole réseau]]
|
|-
| P34 [[IMA4 2016/2017 P34|Interface Haptique, simulateur de formes et de textures]]
|
|-
| P37 [[IMA4 2016/2017 P37|Gamelle connectée]]
|
|-
| P38 [[IMA4 2016/2017 P38|Veilleuse enfant connectée]]
|
|-
| P39 [[IMA4 2016/2017 P39|Projecteur laser]]
|
|-
| P44 [[IMA4 2016/2017 P44|3615 Facebook]]
|
Un Minitel 1 Bistandard Alcatel Telic, 
un connecteur DIN 5 broches[http://www.selectronic.fr/din-cordon-male-5-broches-45.html], 
un Arduino Uno [http://www.selectronic.fr/carte-arduino-uno.html], 
un module Ethernet [http://www.selectronic.fr/shield-ethernet-v2.html]. 
|-
| P46 [[IMA4 2016/2017 P46|Aide anti-gaspillage alimentaire ]]
|
Rfduino DIP board + USB shield, Mouser [http://eu.mouser.com/ProductDetail/RF-Digital-Wireless/RFD90101/?qs=sGAEpiMZZMsrChSOYEGTCSSoddgmKGJ7o1oPrqG%2fa%2fU%3d], 
Rfduino Dual AAA shield, Mouser [http://eu.mouser.com/ProductDetail/RF-Digital-Wireless/RFD22126/?qs=sGAEpiMZZMsrChSOYEGTCTCnakKeCOV7XxQSzqVKQX4%3d], 
Raspberry Pi, 
Clef wifi, 
2 piles de 1,5V AAA , 
Petite BreadBoard, 
1 buzzer, Mouser [http://www.mouser.fr/ProductDetail/TDK/PS1240P02BT/?qs=sGAEpiMZZMtWZVZ%2fjgUYS49cTVUJP3OaWyx1fxdmA7I%3d] , 
1 accéléromètre, mouser [http://www.mouser.fr/ProductDetail/NXP-Freescale/MMA8653FCR1/?qs=sGAEpiMZZMs0JOhy9PM0USp5vOY2ClxOY1G2fK3tzYI%3d] , 
3 LEDs de couleurs différentes , 
Smartphone sous Android, 
3 Résistances CMS 330 Ohms, Mouser [http://www.mouser.fr/ProductDetail/Vishay/CRCW1206330RFKEA/?qs=sGAEpiMZZMvdGkrng054t%252b8cnVAnHPZkGMXtw0W%2fcW8%3d] 
|-
| P47 [[IMA4 2016/2017 P47|Modélisation d’un robot mobile]]
|
|-
| P48 [[IMA4 2016/2017 P48|Surveillance d'un robot mobile]]
|
|}

IMA4 2016/2017 P31

2017-01-25T14:03:41Z

Eprofit : /* Liste des tâches à effectuer */

IMA4 2016/2017 P31

2017-01-25T13:38:00Z

Eprofit : /* Liste des tâches à effectuer */

IMA4 2016/2017 P31

2017-01-25T13:14:12Z

Eprofit : /* Objectif du projet */

IMA4 2016/2017 P31

2017-01-23T15:24:46Z

Eprofit : /* Liste des tâches à effectuer */

IMA4 2016/2017 P31

2017-01-23T15:22:33Z

Eprofit : /* Choix techniques : matériel et logiciel */

IMA4 2016/2017 P31

2017-01-23T15:19:32Z

Eprofit : /* Description du projet */

IMA4 2016/2017 P31

2017-01-23T15:02:16Z

Eprofit : /* Objectif du projet */

IMA4 2016/2017 P31

2017-01-23T14:53:01Z

Eprofit : /* Présentation générale du projet */

IMA4 2016/2017 P31

2017-01-23T14:50:32Z

Eprofit : /* Objectif du projet */

IMA4 2016/2017 P31

2017-01-23T14:47:22Z

Eprofit : *

IMA4 2016/2017 P31

2016-12-15T19:36:19Z

Eprofit : /* Présentation générale du projet */

IMA4 2016/2017 P31

2016-12-15T18:15:17Z

Eprofit : Page créée avec « __TOC__ ==Cahier des charges== ===Présentation générale du projet=== L'enceinte de Polytech Lille est bien connue de ses occupants, ... »

Projet IMA3 P6, 2015/2016, TD2

2016-06-17T13:23:26Z

Eprofit : /* Partie électronique */

= Projet IMA3-SC 2015/2016 : Régulation de température =

== Cahier des charges ==

'''OBJECTIFS'''

Notre projet en système communicant va consister en la réalisation d'un objet connecté.
Nous avons comme objectif au cours de ces séances de réaliser un système permettant de réguler à distance la température d'une pièce.
Celui-ci permettrait de voir et régler la température sur un site WEB mais aussi d'afficher la température sur des afficheurs 7-segment.
Pour simuler l'augmentation de température, on utilisera une résistance chauffante et ainsi pouvoir chauffer en cas de perte de température dans la "pièce". De plus, un ventilateur permettra de diminuer la température.

'''MATERIEL'''

Pour ce faire, nous avons besoin de :

* une Raspberry PI
* un capteur de température
* 2 afficheurs 7-segments
* une led pour faire le °
* une Nanoboard
* une résistance chauffante
* ventialteur

== Séance 1 ==

=== Partie électronique ===

Nous avons dans un premier temps résolu le problème de régulation de température : nous utiliserons un ventilateur pour refroidir et une résistance chauffante pour chauffer.
Chacun de ces deux composants sera alimenté via un transistor.

Voici une ébauche de ce à quoi ressemblera notre système final :

[[Fichier:SchémaProjetSC.jpg]]

Nous avons ensuite pris en main la NanoBoard en faisant en guise d'exercice le tutoriel fourni.

=== Partie informatique ===

Du coté informatique, nous avons naturellement voulu commencer par s'imprégner du langage Arduino, afin de pouvoir créer une maquette de notre projet. Le langage Arduino étant assez proche du langage C, la tâche aura été assez rapide.

Dans un second temps,nous nous sommes attelés à la réalisation de la maquette. Pour ce faire, nous avons utilisé deux LEDs pour symboliser le ventilateur et la résistance, ainsi qu'une sonde de température DS18B20 et 4 afficheurs 7-Segments. Le montage aura été assez simple à réaliser, comme le montre la photographie suivante.

[[Fichier:MontageArduinoExpérimental.jpg]]

Nous avons utilisé deux LEDs, la rouge, branchée sur le port 7 de la RedBoard, représente le ventilateur, la jaune, branchée sur le port 6 de la RedBoard, représente la résistance.

Afin de vérifier que la maquette fonctionne, nous avons aussi évidemment besoin d'un programme Arduino que nous écrirons à la prochaine séance.

== Séance 2 ==

=== Partie électronique ===

Durant la seconde séance, nous avons cherché comment brancher le ventilateur, la résistance chauffante et le capteur.

Nous avons commencé par le plus simple : la sonde de température. Grâce à sa datasheet, il nous a suffit de brancher sur les ports 0V et 5 V ses branches extérieures et sa branche centrale sur une entrée de la Nanoboard.

Pour le branchement du ventilateur et de la résistance chauffante, nous avons comme prévu utilisé des transistors :

*Pour le ventilateur, nous avons utilisé un transistor BC547A qui supporte un courant Icmax de 100mA. De plus nous savons que la FPGA envoie une tension de 3,3V. Il a fallut donc trouver la valeur de la résistance connecté à la base pour pouvoir faire tourner le ventilateur de 12 V ayant une puissance de 1,5W et donc I=0,1A. Pour celà, nous avons utilisé 2 générateurs de tension continue. Le premier relié entre le ventilateur et la masse délivre un tension de 12V. Le second relié entre la résistance et la masse augmente progressivement pour essayer d'atteindre 3,3V tout en regardant l'intensité délivré par le premier générateur qui ne doit pas dépasser 100 mA. Ainsi nous avons trouvé une résistance de 4,7KOhm.
*Pour la résistance chauffante, nous étions partis sur le même principe mais la résistance chauffante demande un courant beaucoup plus élevé. Pour cela, nous avons utilisé un transistor NPN Ti23C avec ic = 1 A. Nous nous sommes alors confronté à un deuxième problème : le courant de saturation demandé est trop grand pour la FPGA. Nous avons alors utilisé un montage de Darlington, avec un premier transistor BC547A pour amplifier l'intensité de base. Ainsi, nous avons trouvé une résistance de 220 Ohm. On aura alors I = 7mA et V = 3,3V. Les caractéristiques de la Résistance chauffante sont les suivantes : Tension d'alimentation de 3.6V et Courant nominal 700mA

<gallery caption="Schémas des montages de test">
Fichier:SchémaVentilo.png|Schéma de l'expérience permettant de déterminer la valeur de la résistance du ventilateur. (''Cliquez pour agrandir'')
Fichier:SchémaRésistance.png|Schéma de l'expérience permettant de déterminer la valeur de la résistance de la résistance chauffante. (''Cliquez pour agrandir'')
</gallery>

=== Partie informatique ===

Lors ce cette seconde séance, nous avons crée le programme Arduino permettant de régir notre maquette.
La principale difficulté que nous avons rencontré à résidé dans le fait que la valeur envoyée de la liaison série vers le programme Arduino n'est pas réceptionnée de la même manière lorsqu'on utilise le moniteur série du programme Arduino, ou lorsqu'on utilise le WebSocket. Nous avons donc choisi dans un premier temps de coder une fonction lisant de manière convenable les informations venant du moniteur série, puis nous avons changé une petite partie du programme pour que celui-ci puisse recevoir les consignes de température de la part d'un utilisateur sur internet.
Il est important de noter que le programme '''Actuellement implémenté''' dans la carte RedBoard est le programme permettant de converser avec un utilisateur via le '''WebSocket''' !

<gallery>
Fichier:Initilisation.JPG|Première partie du code avec initialisation de la liaison série. (''Cliquez pour agrandir'')
Fichier:Arduino2getvoltloop.png|On a ici deux fonctions : l'une permet de récupérer la valeur de température et de la convertir en °C, la seconde est la partie principale de notre programme, l'autre permettant de lire la consigne sur la liaison série, puis d'activer l'un ou l'autre des actionneurs en fonction de celle-ci. (''Cliquez pour agrandir'')
Fichier:Arduinoaffichespi.png|Cette dernière fonction permet d'afficher la valeur désirée sur les quatre digits des afficheurs 7-Segments (''Cliquez pour agrandir'')
</gallery>

Après la création du programme Arduino, l'étape suivante à consisté à initialiser la Raspberry Pi de manière à pouvoir l'utiliser en réseau depuis n'importe quel poste de la salle de projet.
Nous avons tout d'abord connecté le Raspberry Pi à l'ordinateur fixe via un câble série afin de configurer sa carte Ethernet. On utilise le logiciel minicom pour accéder à la Raspberry et l'éditeur de texte nano pour copier les lignes de code suivantes dans le fichier /etc/network/interfaces :

auto eth0
iface eth0 inet static
address 172.26.79.9
netmask 255.255.240.0
gateway 172.26.79.254

On indique aussi le serveur DNS dans le fichier /etc/resolv.conf :

nameserver 193.48.57.34

Nous pouvons maintenant accéder à notre Raspberry Pi via un câble ethernet branché sur le réseau de la salle de projet et la commande ssh pi@172.26.79.5 sur la console de l'ordinateur.
On installe ensuite le package libwebsockets-dev qui contient une bibliothèque C de WebSocket qui sera utile par la suite pour la configuration du WebSocket ainsi que le package apache2 qui permet de créer un serveur HTTP sur Raspberry.Dans le répertoire /var/www, nous copions la fichier HTML de notre page web. Le fichier C du WebSocket se trouve /pi/home. On télécharge aussi la bibliothèque Web 2.0 jquery.js sur le site http://jquery.com/ afin de faciliter l'écriture du programme WebSocket.c.
On constate que le test effectué avec les fichier donnés en exemple dans le sujet fonctionnent bien. On compile et on exécute le fichier C et on tape l’adresse 172.26.79.5 dans un navigateur web pour accéder à l'interface web. Tout fonctionne correctement, nous pourrons utiliser la Raspberry avec notre WebSocket et notre interface web. La commande d'exécution du serveur WebSocket devra être écrite dans le fichier /etc/rc.local pour qu'il s'exécute automatiquement au démarrage du Raspberry.

== Séance 3 ==

=== Partie électronique ===

Nous avons réfléchi au moyen de récupérer la valeur du capteur de température. En effet, la FPGA ne reçoit que des données numériques. Nous avons remarqué en parcourant internet qu'il existait 2 solutions :
*la première était d'utiliser un composant qui fait la conversion mais nous ne l'avons pas demandé
*la deuxième était de convertie par FPGA le signal.

Nous devons comparer deux valeurs : la consigne et la tension du capteur. Pour les simuler, nous les avons mises comme des constantes. De plus, nous avons ajouté une constante qui sert à produire un semblant d'effet d'hystérésis. C'est-à-dire que nous activons le chauffage lorsque la température du capteur moins cette constante est inférieur à la consigne et inversement pour le ventilateur.

[[Fichier:SchémaGénéral.JPG|500px|thumb|center|Schéma général de notre système. (''Cliquez pour agrandir'')]]

Nous avons réfléchi au moyen de récupérer la valeur du capteur de température. En effet, la FPGA ne reçoit que des données numériques. Nous avons remarqué en parcourant internet qu'il existait 2 solutions :
*la première était d'utiliser un composant qui fait la conversion mais nous ne l'avons pas demandé
*la seconde était d'effectuer une conversion simple rampe grâce à notre Nanoboard. Pour cela nous comparons la valeur analogique (entrée sur le port HA5) avec un compteur qui s'incrémente sur front montant de l'horloge interne à la Nanoboard. Ainsi, quand elles sont égales, on récupère la valeur du compteur (correspondant alors à la valeur captée), et nous réinitialisons le compteur pour faire une nouvelle mesure.

[[Fichier:ConversionSimpleRampe.JPG|500px|thumb|center|Conversion simple rampe via Altium. (''Cliquez pour agrandir'')]]

=== Partie informatique ===

L'objectif de cette dernière séance en terme d'informatique est de réaliser le WebSocket et la page HTML de notre application.
Cette dernière est relativement simple à réaliser dans la mesure où beaucoup d'éléments de la page donnée à titre d'exemple peuvent-être repris pour être adaptés à ce que l'on recherche.

<gallery>
Fichier:Corpshtml.png|Corps du fichier HTML permettant simplement de créer une barre d'insertion, et un bouton valider. (''Cliquez pour agrandir'')
Fichier:Incdec.png|Deux boutons permettant, dans l'optique d'ajouter deux boutons, de décrémenter ou t'incrémenter la valeur de température sélectionnée après un clic sur l'un des deux boutons. (''Cliquez pour agrandir'')
</gallery>

Enfin, la partie la plus délicate du domaine informatique de ce projet aura été de configurer convenablement le WebSocket, de manière à pouvoir recevoir des valeurs depuis le navigateur.
Pour ce faire, nous devons pour commencer démarrer la liaison série à 9600 Bauds, et donc ajouter au préalable toutes les fonctions nécéssaires à l'entretien et l'utilisation de cette liaison série.

<gallery>
Fichier:WebSocket1.png|Déclaration des fonctions utilisées pour l'utilisation de la liaison série. (''Cliquez pour agrandir'')
Fichier:MainWebSocket.png|Démarrage de la liaison série, puis on la garde ouverte avec un while infini. (''Cliquez pour agrandir'')
</gallery>

Enfin, il convient de changer les "cases" au début du WebSocket de manière à récuperer la valeur "in" envoyée via la liaison série.
Dans notre cas, il est seulement utile de changer le cas où on reçoit des informations du navigateur; on rajoute donc simplement les lignes suivantes :

int température;
... (on rentre dans le case LWS_CALLBACK_RECEIVE)
sscanf(in,"%d",&temperature);
if (write(sd,&temperature,sizeof(char))!=1){perror......}

[[Fichier:WebSocket2.png|500px|thumb|center|Partie du code du WebSocket permettant de gérer la réception et l'émission de données. (''Cliquez pour agrandir'')]]

Ce qui nous permet donc de récupérer les valeurs de températures de les renvoyer dans la liaison série vers le système.
Après plusieurs modifications mineures, on obtient bien le résultat escompté avec la carte RedBoard, comme on peut le constater dans la vidéo suivante :
(On rappelle que la LED rouge correspond au ventilateur, et la jaune à la résistance)

[[Média:Video-1466005707.mp4]] (''Cliquez pour lancer la vidéo'')

== Démonstration ==

== Conclusion ==

Bien qu'il ait été compliqué de terminer ce projet, nous pensons avoir rempli tout de même une bonne partie du cahier des charges.
Nous avons acquis de nombreuses compétences dans le domaine informatique : Création de programmes Arduino, Prise en main d'une Raspberry Pi, etc; mais aussi dans le domaine électronique comme la programmation de Nanoboard.
Malgré l'échec de la partie électronique, nous sommes tout de même satisfait que la partie informatique ait très bien répondu à nos attentes.
De plus, bien que nous ayons cruellement manqué de temps en classe (et d'effectif), nous sommes satisfaits d'avoir pu tester ce qu'il se fait en IMA4.
Enfin, nous sommes satisfaits d'avoir participé à ce type de projet, qui renforce aussi les compétences humaines, comme le travail en équipe, et la réflexion/concertation en groupe; donnant un aperçu de notre (espérons-le) proche futur d'ingénieur.

Projet IMA3 P6, 2015/2016, TD2

2016-06-17T10:02:37Z

Eprofit : /* Partie électronique */

= Projet IMA3-SC 2015/2016 : Régulation de température =

== Cahier des charges ==

'''OBJECTIFS'''

Notre projet en système communicant va consister en la réalisation d'un objet connecté.
Nous avons comme objectif au cours de ces séances de réaliser un système permettant de réguler à distance la température d'une pièce.
Celui-ci permettrait de voir et régler la température sur un site WEB mais aussi d'afficher la température sur des afficheurs 7-segment.
Pour simuler l'augmentation de température, on utilisera une résistance chauffante et ainsi pouvoir chauffer en cas de perte de température dans la "pièce". De plus, un ventilateur permettra de diminuer la température.

'''MATERIEL'''

Pour ce faire, nous avons besoin de :

* une Raspberry PI
* un capteur de température
* 2 afficheurs 7-segments
* une led pour faire le °
* une Nanoboard
* une résistance chauffante
* ventialteur

== Séance 1 ==

=== Partie électronique ===

Nous avons dans un premier temps résolu le problème de régulation de température : nous utiliserons un ventilateur pour refroidir et une résistance chauffante pour chauffer.
Chacun de ces deux composants sera alimenté via un transistor.

Voici une ébauche de ce à quoi ressemblera notre système final :

[[Fichier:SchémaProjetSC.jpg]]

Nous avons ensuite pris en main la NanoBoard en faisant en guise d'exercice le tutoriel fourni.

=== Partie informatique ===

Du coté informatique, nous avons naturellement voulu commencer par s'imprégner du langage Arduino, afin de pouvoir créer une maquette de notre projet. Le langage Arduino étant assez proche du langage C, la tâche aura été assez rapide.

Dans un second temps,nous nous sommes attelés à la réalisation de la maquette. Pour ce faire, nous avons utilisé deux LEDs pour symboliser le ventilateur et la résistance, ainsi qu'une sonde de température DS18B20 et 4 afficheurs 7-Segments. Le montage aura été assez simple à réaliser, comme le montre la photographie suivante.

[[Fichier:MontageArduinoExpérimental.jpg]]

Nous avons utilisé deux LEDs, la rouge, branchée sur le port 7 de la RedBoard, représente le ventilateur, la jaune, branchée sur le port 6 de la RedBoard, représente la résistance.

Afin de vérifier que la maquette fonctionne, nous avons aussi évidemment besoin d'un programme Arduino que nous écrirons à la prochaine séance.

== Séance 2 ==

=== Partie électronique ===

Durant la seconde séance, nous avons cherché comment brancher le ventilateur, la résistance chauffante et le capteur.

Nous avons commencé par le plus simple : la sonde de température. Grâce à sa datasheet, il nous a suffit de brancher sur les ports 0V et 5 V ses branches extérieures et sa branche centrale sur une entrée de la Nanoboard.

Pour le branchement du ventilateur et de la résistance chauffante, nous avons comme prévu utilisé des transistors :

*Pour le ventilateur, nous avons utilisé un transistor BC547A qui supporte un courant Icmax de 100mA. De plus nous savons que la FPGA envoie une tension de 3,3V. Il a fallut donc trouver la valeur de la résistance connecté à la base pour pouvoir faire tourner le ventilateur de 12 V ayant une puissance de 1,5W et donc I=0,1A. Pour celà, nous avons utilisé 2 générateurs de tension continue. Le premier relié entre le ventilateur et la masse délivre un tension de 12V. Le second relié entre la résistance et la masse augmente progressivement pour essayer d'atteindre 3,3V tout en regardant l'intensité délivré par le premier générateur qui ne doit pas dépasser 100 mA. Ainsi nous avons trouvé une résistance de 4,7KOhm.
*Pour la résistance chauffante, nous étions partis sur le même principe mais la résistance chauffante demande un courant beaucoup plus élevé. Pour cela, nous avons utilisé un transistor NPN Ti23C avec ic = 1 A. Nous nous sommes alors confronté à un deuxième problème : le courant de saturation demandé est trop grand pour la FPGA. Nous avons alors utilisé un montage de Darlington, avec un premier transistor BC547A pour amplifier l'intensité de base. Ainsi, nous avons trouvé une résistance de 220 Ohm. On aura alors I = 7mA et V = 3,3V. Les caractéristiques de la Résistance chauffante sont les suivantes : Tension d'alimentation de 3.6V et Courant nominal 700mA

<gallery caption="Schémas des montages de test">
Fichier:SchémaVentilo.png|Schéma de l'expérience permettant de déterminer la valeur de la résistance du ventilateur. (''Cliquez pour agrandir'')
Fichier:SchémaRésistance.png|Schéma de l'expérience permettant de déterminer la valeur de la résistance de la résistance chauffante. (''Cliquez pour agrandir'')
</gallery>

=== Partie informatique ===

Lors ce cette seconde séance, nous avons crée le programme Arduino permettant de régir notre maquette.
La principale difficulté que nous avons rencontré à résidé dans le fait que la valeur envoyée de la liaison série vers le programme Arduino n'est pas réceptionnée de la même manière lorsqu'on utilise le moniteur série du programme Arduino, ou lorsqu'on utilise le WebSocket. Nous avons donc choisi dans un premier temps de coder une fonction lisant de manière convenable les informations venant du moniteur série, puis nous avons changé une petite partie du programme pour que celui-ci puisse recevoir les consignes de température de la part d'un utilisateur sur internet.
Il est important de noter que le programme '''Actuellement implémenté''' dans la carte RedBoard est le programme permettant de converser avec un utilisateur via le '''WebSocket''' !

<gallery>
Fichier:Initilisation.JPG|Première partie du code avec initialisation de la liaison série. (''Cliquez pour agrandir'')
Fichier:Arduino2getvoltloop.png|On a ici deux fonctions : l'une permet de récupérer la valeur de température et de la convertir en °C, la seconde est la partie principale de notre programme, l'autre permettant de lire la consigne sur la liaison série, puis d'activer l'un ou l'autre des actionneurs en fonction de celle-ci. (''Cliquez pour agrandir'')
Fichier:Arduinoaffichespi.png|Cette dernière fonction permet d'afficher la valeur désirée sur les quatre digits des afficheurs 7-Segments (''Cliquez pour agrandir'')
</gallery>

Après la création du programme Arduino, l'étape suivante à consisté à initialiser la Raspberry Pi de manière à pouvoir l'utiliser en réseau depuis n'importe quel poste de la salle de projet.
Nous avons tout d'abord connecté le Raspberry Pi à l'ordinateur fixe via un câble série afin de configurer sa carte Ethernet. On utilise le logiciel minicom pour accéder à la Raspberry et l'éditeur de texte nano pour copier les lignes de code suivantes dans le fichier /etc/network/interfaces :

auto eth0
iface eth0 inet static
address 172.26.79.9
netmask 255.255.240.0
gateway 172.26.79.254

On indique aussi le serveur DNS dans le fichier /etc/resolv.conf :

nameserver 193.48.57.34

Nous pouvons maintenant accéder à notre Raspberry Pi via un câble ethernet branché sur le réseau de la salle de projet et la commande ssh pi@172.26.79.5 sur la console de l'ordinateur.
On installe ensuite le package libwebsockets-dev qui contient une bibliothèque C de WebSocket qui sera utile par la suite pour la configuration du WebSocket ainsi que le package apache2 qui permet de créer un serveur HTTP sur Raspberry.Dans le répertoire /var/www, nous copions la fichier HTML de notre page web. Le fichier C du WebSocket se trouve /pi/home. On télécharge aussi la bibliothèque Web 2.0 jquery.js sur le site http://jquery.com/ afin de faciliter l'écriture du programme WebSocket.c.
On constate que le test effectué avec les fichier donnés en exemple dans le sujet fonctionnent bien. On compile et on exécute le fichier C et on tape l’adresse 172.26.79.5 dans un navigateur web pour accéder à l'interface web. Tout fonctionne correctement, nous pourrons utiliser la Raspberry avec notre WebSocket et notre interface web. La commande d'exécution du serveur WebSocket devra être écrite dans le fichier /etc/rc.local pour qu'il s'exécute automatiquement au démarrage du Raspberry.

== Séance 3 ==

=== Partie électronique ===

Nous avons réfléchi au moyen de récupérer la valeur du capteur de température. En effet, la FPGA ne reçoit que des données numériques. Nous avons remarqué en parcourant internet qu'il existait 2 solutions :
*la première était d'utiliser un composant qui fait la conversion mais nous ne l'avons pas demandé
*la deuxième était de convertie par FPGA le signal.

Nous devons comparer deux valeurs : la consigne et la tension du capteur. Pour les simuler, nous les avons mises comme des constantes. De plus, nous avons ajouté une constante qui sert à produire un semblant d'effet d'hystérésis. C'est-à-dire que nous activons le chauffage lorsque la température du capteur moins cette constante est inférieur à la consigne et inversement pour le ventilateur.

Schéma Altium réalisé lors de cette séance :

Nous avons réfléchi au moyen de récupérer la valeur du capteur de température. En effet, la FPGA ne reçoit que des données numériques. Nous avons remarqué en parcourant internet qu'il existait 2 solutions :
la première était d'utiliser un composant qui fait la conversion mais nous ne l'avons pas demandé
la deuxième était d'effectuer une conversion simple rampe grâce à Altium. Pour celà nous comparons la valeur analogique (HA5) avec un compteur qui s'incrémente sur front montant de l'horloge. Ainsi, quand elles sont égales, nous réinitialisons le compteur pour avoir une nouvelle valeur. De plus, lorsque les deux valeurs sont égales, grâce au MUX, nous récupérons la valeur du compteur.

=== Partie informatique ===

L'objectif de cette dernière séance en terme d'informatique est de réaliser le WebSocket et la page HTML de notre application.
Cette dernière est relativement simple à réaliser dans la mesure où beaucoup d'éléments de la page donnée à titre d'exemple peuvent-être repris pour être adaptés à ce que l'on recherche.

<gallery>
Fichier:Corpshtml.png|Corps du fichier HTML permettant simplement de créer une barre d'insertion, et un bouton valider. (''Cliquez pour agrandir'')
Fichier:Incdec.png|Deux boutons permettant, dans l'optique d'ajouter deux boutons, de décrémenter ou t'incrémenter la valeur de température sélectionnée après un clic sur l'un des deux boutons. (''Cliquez pour agrandir'')
</gallery>

Enfin, la partie la plus délicate du domaine informatique de ce projet aura été de configurer convenablement le WebSocket, de manière à pouvoir recevoir des valeurs depuis le navigateur.
Pour ce faire, nous devons pour commencer démarrer la liaison série à 9600 Bauds, et donc ajouter au préalable toutes les fonctions nécéssaires à l'entretien et l'utilisation de cette liaison série.

<gallery>
Fichier:WebSocket1.png|Déclaration des fonctions utilisées pour l'utilisation de la liaison série. (''Cliquez pour agrandir'')
Fichier:MainWebSocket.png|Démarrage de la liaison série, puis on la garde ouverte avec un while infini. (''Cliquez pour agrandir'')
</gallery>

Enfin, il convient de changer les "cases" au début du WebSocket de manière à récuperer la valeur "in" envoyée via la liaison série.
Dans notre cas, il est seulement utile de changer le cas où on reçoit des informations du navigateur; on rajoute donc simplement les lignes suivantes :

int température;
... (on rentre dans le case LWS_CALLBACK_RECEIVE)
sscanf(in,"%d",&temperature);
if (write(sd,&temperature,sizeof(char))!=1){perror......}

[[Fichier:WebSocket2.png|500px|thumb|center|Partie du code du WebSocket permettant de gérer la réception et l'émission de données. (''Cliquez pour agrandir'')]]

Ce qui nous permet donc de récupérer les valeurs de températures de les renvoyer dans la liaison série vers le système.
Après plusieurs modifications mineures, on obtient bien le résultat escompté avec la carte RedBoard, comme on peut le constater dans la vidéo suivante :
(On rappelle que la LED rouge correspond au ventilateur, et la jaune à la résistance)

[[Média:Video-1466005707.mp4]] (''Cliquez pour lancer la vidéo'')

== Démonstration ==

== Conclusion ==

Bien qu'il ait été compliqué de terminer ce projet, nous pensons avoir rempli tout de même une bonne partie du cahier des charges.
Nous avons acquis de nombreuses compétences dans le domaine informatique : Création de programmes Arduino, Prise en main d'une Raspberry Pi, etc; mais aussi dans le domaine électronique comme la programmation de Nanoboard.
Malgré l'échec de la partie électronique, nous sommes tout de même satisfait que la partie informatique ait très bien répondu à nos attentes.
De plus, bien que nous ayons cruellement manqué de temps en classe (et d'effectif), nous sommes satisfaits d'avoir pu tester ce qu'il se fait en IMA4.
Enfin, nous sommes satisfaits d'avoir participé à ce type de projet, qui renforce aussi les compétences humaines, comme le travail en équipe, et la réflexion/concertation en groupe; donnant un aperçu de notre (espérons-le) proche futur d'ingénieur.

Fichier:FichiersRaspberry.zip

2016-06-17T09:56:37Z

Eprofit : Archive contenant les fichiers utilisés sur la RaspberryPi 06 de la salle de projet pour le groupe PROFIT/SENAFFE

Archive contenant les fichiers utilisés sur la RaspberryPi 06 de la salle de projet pour le groupe PROFIT/SENAFFE

Fichier:ConversionSimpleRampe.JPG

2016-06-17T09:54:01Z

Eprofit :

Fichier:SchémaGénéral.JPG

2016-06-17T09:52:31Z

Eprofit :

Projet IMA3 P6, 2015/2016, TD2

2016-06-17T09:49:43Z

Eprofit : /* Conclusion */

= Projet IMA3-SC 2015/2016 : Régulation de température =

== Cahier des charges ==

'''OBJECTIFS'''

Notre projet en système communicant va consister en la réalisation d'un objet connecté.
Nous avons comme objectif au cours de ces séances de réaliser un système permettant de réguler à distance la température d'une pièce.
Celui-ci permettrait de voir et régler la température sur un site WEB mais aussi d'afficher la température sur des afficheurs 7-segment.
Pour simuler l'augmentation de température, on utilisera une résistance chauffante et ainsi pouvoir chauffer en cas de perte de température dans la "pièce". De plus, un ventilateur permettra de diminuer la température.

'''MATERIEL'''

Pour ce faire, nous avons besoin de :

* une Raspberry PI
* un capteur de température
* 2 afficheurs 7-segments
* une led pour faire le °
* une Nanoboard
* une résistance chauffante
* ventialteur

== Séance 1 ==

=== Partie électronique ===

Nous avons dans un premier temps résolu le problème de régulation de température : nous utiliserons un ventilateur pour refroidir et une résistance chauffante pour chauffer.
Chacun de ces deux composants sera alimenté via un transistor.

Voici une ébauche de ce à quoi ressemblera notre système final :

[[Fichier:SchémaProjetSC.jpg]]

Nous avons ensuite pris en main la NanoBoard en faisant en guise d'exercice le tutoriel fourni.

=== Partie informatique ===

Du coté informatique, nous avons naturellement voulu commencer par s'imprégner du langage Arduino, afin de pouvoir créer une maquette de notre projet. Le langage Arduino étant assez proche du langage C, la tâche aura été assez rapide.

Dans un second temps,nous nous sommes attelés à la réalisation de la maquette. Pour ce faire, nous avons utilisé deux LEDs pour symboliser le ventilateur et la résistance, ainsi qu'une sonde de température DS18B20 et 4 afficheurs 7-Segments. Le montage aura été assez simple à réaliser, comme le montre la photographie suivante.

[[Fichier:MontageArduinoExpérimental.jpg]]

Nous avons utilisé deux LEDs, la rouge, branchée sur le port 7 de la RedBoard, représente le ventilateur, la jaune, branchée sur le port 6 de la RedBoard, représente la résistance.

Afin de vérifier que la maquette fonctionne, nous avons aussi évidemment besoin d'un programme Arduino que nous écrirons à la prochaine séance.

== Séance 2 ==

=== Partie électronique ===

Durant la seconde séance, nous avons cherché comment brancher le ventilateur, la résistance chauffante et le capteur.

Nous avons commencé par le plus simple : la sonde de température. Grâce à sa datasheet, il nous a suffit de brancher sur les ports 0V et 5 V ses branches extérieures et sa branche centrale sur une entrée de la Nanoboard.

Pour le branchement du ventilateur et de la résistance chauffante, nous avons comme prévu utilisé des transistors :

*Pour le ventilateur, nous avons utilisé un transistor BC547A qui supporte un courant Icmax de 100mA. De plus nous savons que la FPGA envoie une tension de 3,3V. Il a fallut donc trouver la valeur de la résistance connecté à la base pour pouvoir faire tourner le ventilateur de 12 V ayant une puissance de 1,5W et donc I=0,1A. Pour celà, nous avons utilisé 2 générateurs de tension continue. Le premier relié entre le ventilateur et la masse délivre un tension de 12V. Le second relié entre la résistance et la masse augmente progressivement pour essayer d'atteindre 3,3V tout en regardant l'intensité délivré par le premier générateur qui ne doit pas dépasser 100 mA. Ainsi nous avons trouvé une résistance de 4,7KOhm.
*Pour la résistance chauffante, nous étions partis sur le même principe mais la résistance chauffante demande un courant beaucoup plus élevé. Pour cela, nous avons utilisé un transistor NPN Ti23C avec ic = 1 A. Nous nous sommes alors confronté à un deuxième problème : le courant de saturation demandé est trop grand pour la FPGA. Nous avons alors utilisé un montage de Darlington, avec un premier transistor BC547A pour amplifier l'intensité de base. Ainsi, nous avons trouvé une résistance de 220 Ohm. On aura alors I = 7mA et V = 3,3V. Les caractéristiques de la Résistance chauffante sont les suivantes : Tension d'alimentation de 3.6V et Courant nominal 700mA

<gallery caption="Schémas des montages de test">
Fichier:SchémaVentilo.png|Schéma de l'expérience permettant de déterminer la valeur de la résistance du ventilateur. (''Cliquez pour agrandir'')
Fichier:SchémaRésistance.png|Schéma de l'expérience permettant de déterminer la valeur de la résistance de la résistance chauffante. (''Cliquez pour agrandir'')
</gallery>

=== Partie informatique ===

Lors ce cette seconde séance, nous avons crée le programme Arduino permettant de régir notre maquette.
La principale difficulté que nous avons rencontré à résidé dans le fait que la valeur envoyée de la liaison série vers le programme Arduino n'est pas réceptionnée de la même manière lorsqu'on utilise le moniteur série du programme Arduino, ou lorsqu'on utilise le WebSocket. Nous avons donc choisi dans un premier temps de coder une fonction lisant de manière convenable les informations venant du moniteur série, puis nous avons changé une petite partie du programme pour que celui-ci puisse recevoir les consignes de température de la part d'un utilisateur sur internet.
Il est important de noter que le programme '''Actuellement implémenté''' dans la carte RedBoard est le programme permettant de converser avec un utilisateur via le '''WebSocket''' !

<gallery>
Fichier:Initilisation.JPG|Première partie du code avec initialisation de la liaison série. (''Cliquez pour agrandir'')
Fichier:Arduino2getvoltloop.png|On a ici deux fonctions : l'une permet de récupérer la valeur de température et de la convertir en °C, la seconde est la partie principale de notre programme, l'autre permettant de lire la consigne sur la liaison série, puis d'activer l'un ou l'autre des actionneurs en fonction de celle-ci. (''Cliquez pour agrandir'')
Fichier:Arduinoaffichespi.png|Cette dernière fonction permet d'afficher la valeur désirée sur les quatre digits des afficheurs 7-Segments (''Cliquez pour agrandir'')
</gallery>

Après la création du programme Arduino, l'étape suivante à consisté à initialiser la Raspberry Pi de manière à pouvoir l'utiliser en réseau depuis n'importe quel poste de la salle de projet.
Nous avons tout d'abord connecté le Raspberry Pi à l'ordinateur fixe via un câble série afin de configurer sa carte Ethernet. On utilise le logiciel minicom pour accéder à la Raspberry et l'éditeur de texte nano pour copier les lignes de code suivantes dans le fichier /etc/network/interfaces :

auto eth0
iface eth0 inet static
address 172.26.79.9
netmask 255.255.240.0
gateway 172.26.79.254

On indique aussi le serveur DNS dans le fichier /etc/resolv.conf :

nameserver 193.48.57.34

Nous pouvons maintenant accéder à notre Raspberry Pi via un câble ethernet branché sur le réseau de la salle de projet et la commande ssh pi@172.26.79.5 sur la console de l'ordinateur.
On installe ensuite le package libwebsockets-dev qui contient une bibliothèque C de WebSocket qui sera utile par la suite pour la configuration du WebSocket ainsi que le package apache2 qui permet de créer un serveur HTTP sur Raspberry.Dans le répertoire /var/www, nous copions la fichier HTML de notre page web. Le fichier C du WebSocket se trouve /pi/home. On télécharge aussi la bibliothèque Web 2.0 jquery.js sur le site http://jquery.com/ afin de faciliter l'écriture du programme WebSocket.c.
On constate que le test effectué avec les fichier donnés en exemple dans le sujet fonctionnent bien. On compile et on exécute le fichier C et on tape l’adresse 172.26.79.5 dans un navigateur web pour accéder à l'interface web. Tout fonctionne correctement, nous pourrons utiliser la Raspberry avec notre WebSocket et notre interface web. La commande d'exécution du serveur WebSocket devra être écrite dans le fichier /etc/rc.local pour qu'il s'exécute automatiquement au démarrage du Raspberry.

== Séance 3 ==

=== Partie électronique ===

Nous avons réfléchi au moyen de récupérer la valeur du capteur de température. En effet, la FPGA ne reçoit que des données numériques. Nous avons remarqué en parcourant internet qu'il existait 2 solutions :
la première était d'utiliser un composant qui fait la conversion mais nous ne l'avons pas demandé
la deuxième était de convertie par FPGA le signal.

=== Partie informatique ===

L'objectif de cette dernière séance en terme d'informatique est de réaliser le WebSocket et la page HTML de notre application.
Cette dernière est relativement simple à réaliser dans la mesure où beaucoup d'éléments de la page donnée à titre d'exemple peuvent-être repris pour être adaptés à ce que l'on recherche.

<gallery>
Fichier:Corpshtml.png|Corps du fichier HTML permettant simplement de créer une barre d'insertion, et un bouton valider. (''Cliquez pour agrandir'')
Fichier:Incdec.png|Deux boutons permettant, dans l'optique d'ajouter deux boutons, de décrémenter ou t'incrémenter la valeur de température sélectionnée après un clic sur l'un des deux boutons. (''Cliquez pour agrandir'')
</gallery>

Enfin, la partie la plus délicate du domaine informatique de ce projet aura été de configurer convenablement le WebSocket, de manière à pouvoir recevoir des valeurs depuis le navigateur.
Pour ce faire, nous devons pour commencer démarrer la liaison série à 9600 Bauds, et donc ajouter au préalable toutes les fonctions nécéssaires à l'entretien et l'utilisation de cette liaison série.

<gallery>
Fichier:WebSocket1.png|Déclaration des fonctions utilisées pour l'utilisation de la liaison série. (''Cliquez pour agrandir'')
Fichier:MainWebSocket.png|Démarrage de la liaison série, puis on la garde ouverte avec un while infini. (''Cliquez pour agrandir'')
</gallery>

Enfin, il convient de changer les "cases" au début du WebSocket de manière à récuperer la valeur "in" envoyée via la liaison série.
Dans notre cas, il est seulement utile de changer le cas où on reçoit des informations du navigateur; on rajoute donc simplement les lignes suivantes :

int température;
... (on rentre dans le case LWS_CALLBACK_RECEIVE)
sscanf(in,"%d",&temperature);
if (write(sd,&temperature,sizeof(char))!=1){perror......}

[[Fichier:WebSocket2.png|500px|thumb|center|Partie du code du WebSocket permettant de gérer la réception et l'émission de données. (''Cliquez pour agrandir'')]]

Ce qui nous permet donc de récupérer les valeurs de températures de les renvoyer dans la liaison série vers le système.
Après plusieurs modifications mineures, on obtient bien le résultat escompté avec la carte RedBoard, comme on peut le constater dans la vidéo suivante :
(On rappelle que la LED rouge correspond au ventilateur, et la jaune à la résistance)

[[Média:Video-1466005707.mp4]] (''Cliquez pour lancer la vidéo'')

== Démonstration ==

== Conclusion ==

Bien qu'il ait été compliqué de terminer ce projet, nous pensons avoir rempli tout de même une bonne partie du cahier des charges.
Nous avons acquis de nombreuses compétences dans le domaine informatique : Création de programmes Arduino, Prise en main d'une Raspberry Pi, etc; mais aussi dans le domaine électronique comme la programmation de Nanoboard.
Malgré l'échec de la partie électronique, nous sommes tout de même satisfait que la partie informatique ait très bien répondu à nos attentes.
De plus, bien que nous ayons cruellement manqué de temps en classe (et d'effectif), nous sommes satisfaits d'avoir pu tester ce qu'il se fait en IMA4.
Enfin, nous sommes satisfaits d'avoir participé à ce type de projet, qui renforce aussi les compétences humaines, comme le travail en équipe, et la réflexion/concertation en groupe; donnant un aperçu de notre (espérons-le) proche futur d'ingénieur.

Projet IMA3 P6, 2015/2016, TD2

2016-06-17T09:49:14Z

Eprofit : /* Conclusion */

= Projet IMA3-SC 2015/2016 : Régulation de température =

== Cahier des charges ==

'''OBJECTIFS'''

Notre projet en système communicant va consister en la réalisation d'un objet connecté.
Nous avons comme objectif au cours de ces séances de réaliser un système permettant de réguler à distance la température d'une pièce.
Celui-ci permettrait de voir et régler la température sur un site WEB mais aussi d'afficher la température sur des afficheurs 7-segment.
Pour simuler l'augmentation de température, on utilisera une résistance chauffante et ainsi pouvoir chauffer en cas de perte de température dans la "pièce". De plus, un ventilateur permettra de diminuer la température.

'''MATERIEL'''

Pour ce faire, nous avons besoin de :

* une Raspberry PI
* un capteur de température
* 2 afficheurs 7-segments
* une led pour faire le °
* une Nanoboard
* une résistance chauffante
* ventialteur

== Séance 1 ==

=== Partie électronique ===

Nous avons dans un premier temps résolu le problème de régulation de température : nous utiliserons un ventilateur pour refroidir et une résistance chauffante pour chauffer.
Chacun de ces deux composants sera alimenté via un transistor.

Voici une ébauche de ce à quoi ressemblera notre système final :

[[Fichier:SchémaProjetSC.jpg]]

Nous avons ensuite pris en main la NanoBoard en faisant en guise d'exercice le tutoriel fourni.

=== Partie informatique ===

Du coté informatique, nous avons naturellement voulu commencer par s'imprégner du langage Arduino, afin de pouvoir créer une maquette de notre projet. Le langage Arduino étant assez proche du langage C, la tâche aura été assez rapide.

Dans un second temps,nous nous sommes attelés à la réalisation de la maquette. Pour ce faire, nous avons utilisé deux LEDs pour symboliser le ventilateur et la résistance, ainsi qu'une sonde de température DS18B20 et 4 afficheurs 7-Segments. Le montage aura été assez simple à réaliser, comme le montre la photographie suivante.

[[Fichier:MontageArduinoExpérimental.jpg]]

Nous avons utilisé deux LEDs, la rouge, branchée sur le port 7 de la RedBoard, représente le ventilateur, la jaune, branchée sur le port 6 de la RedBoard, représente la résistance.

Afin de vérifier que la maquette fonctionne, nous avons aussi évidemment besoin d'un programme Arduino que nous écrirons à la prochaine séance.

== Séance 2 ==

=== Partie électronique ===

Durant la seconde séance, nous avons cherché comment brancher le ventilateur, la résistance chauffante et le capteur.

Nous avons commencé par le plus simple : la sonde de température. Grâce à sa datasheet, il nous a suffit de brancher sur les ports 0V et 5 V ses branches extérieures et sa branche centrale sur une entrée de la Nanoboard.

Pour le branchement du ventilateur et de la résistance chauffante, nous avons comme prévu utilisé des transistors :

*Pour le ventilateur, nous avons utilisé un transistor BC547A qui supporte un courant Icmax de 100mA. De plus nous savons que la FPGA envoie une tension de 3,3V. Il a fallut donc trouver la valeur de la résistance connecté à la base pour pouvoir faire tourner le ventilateur de 12 V ayant une puissance de 1,5W et donc I=0,1A. Pour celà, nous avons utilisé 2 générateurs de tension continue. Le premier relié entre le ventilateur et la masse délivre un tension de 12V. Le second relié entre la résistance et la masse augmente progressivement pour essayer d'atteindre 3,3V tout en regardant l'intensité délivré par le premier générateur qui ne doit pas dépasser 100 mA. Ainsi nous avons trouvé une résistance de 4,7KOhm.
*Pour la résistance chauffante, nous étions partis sur le même principe mais la résistance chauffante demande un courant beaucoup plus élevé. Pour cela, nous avons utilisé un transistor NPN Ti23C avec ic = 1 A. Nous nous sommes alors confronté à un deuxième problème : le courant de saturation demandé est trop grand pour la FPGA. Nous avons alors utilisé un montage de Darlington, avec un premier transistor BC547A pour amplifier l'intensité de base. Ainsi, nous avons trouvé une résistance de 220 Ohm. On aura alors I = 7mA et V = 3,3V. Les caractéristiques de la Résistance chauffante sont les suivantes : Tension d'alimentation de 3.6V et Courant nominal 700mA

<gallery caption="Schémas des montages de test">
Fichier:SchémaVentilo.png|Schéma de l'expérience permettant de déterminer la valeur de la résistance du ventilateur. (''Cliquez pour agrandir'')
Fichier:SchémaRésistance.png|Schéma de l'expérience permettant de déterminer la valeur de la résistance de la résistance chauffante. (''Cliquez pour agrandir'')
</gallery>

=== Partie informatique ===

Lors ce cette seconde séance, nous avons crée le programme Arduino permettant de régir notre maquette.
La principale difficulté que nous avons rencontré à résidé dans le fait que la valeur envoyée de la liaison série vers le programme Arduino n'est pas réceptionnée de la même manière lorsqu'on utilise le moniteur série du programme Arduino, ou lorsqu'on utilise le WebSocket. Nous avons donc choisi dans un premier temps de coder une fonction lisant de manière convenable les informations venant du moniteur série, puis nous avons changé une petite partie du programme pour que celui-ci puisse recevoir les consignes de température de la part d'un utilisateur sur internet.
Il est important de noter que le programme '''Actuellement implémenté''' dans la carte RedBoard est le programme permettant de converser avec un utilisateur via le '''WebSocket''' !

<gallery>
Fichier:Initilisation.JPG|Première partie du code avec initialisation de la liaison série. (''Cliquez pour agrandir'')
Fichier:Arduino2getvoltloop.png|On a ici deux fonctions : l'une permet de récupérer la valeur de température et de la convertir en °C, la seconde est la partie principale de notre programme, l'autre permettant de lire la consigne sur la liaison série, puis d'activer l'un ou l'autre des actionneurs en fonction de celle-ci. (''Cliquez pour agrandir'')
Fichier:Arduinoaffichespi.png|Cette dernière fonction permet d'afficher la valeur désirée sur les quatre digits des afficheurs 7-Segments (''Cliquez pour agrandir'')
</gallery>

Après la création du programme Arduino, l'étape suivante à consisté à initialiser la Raspberry Pi de manière à pouvoir l'utiliser en réseau depuis n'importe quel poste de la salle de projet.
Nous avons tout d'abord connecté le Raspberry Pi à l'ordinateur fixe via un câble série afin de configurer sa carte Ethernet. On utilise le logiciel minicom pour accéder à la Raspberry et l'éditeur de texte nano pour copier les lignes de code suivantes dans le fichier /etc/network/interfaces :

auto eth0
iface eth0 inet static
address 172.26.79.9
netmask 255.255.240.0
gateway 172.26.79.254

On indique aussi le serveur DNS dans le fichier /etc/resolv.conf :

nameserver 193.48.57.34

Nous pouvons maintenant accéder à notre Raspberry Pi via un câble ethernet branché sur le réseau de la salle de projet et la commande ssh pi@172.26.79.5 sur la console de l'ordinateur.
On installe ensuite le package libwebsockets-dev qui contient une bibliothèque C de WebSocket qui sera utile par la suite pour la configuration du WebSocket ainsi que le package apache2 qui permet de créer un serveur HTTP sur Raspberry.Dans le répertoire /var/www, nous copions la fichier HTML de notre page web. Le fichier C du WebSocket se trouve /pi/home. On télécharge aussi la bibliothèque Web 2.0 jquery.js sur le site http://jquery.com/ afin de faciliter l'écriture du programme WebSocket.c.
On constate que le test effectué avec les fichier donnés en exemple dans le sujet fonctionnent bien. On compile et on exécute le fichier C et on tape l’adresse 172.26.79.5 dans un navigateur web pour accéder à l'interface web. Tout fonctionne correctement, nous pourrons utiliser la Raspberry avec notre WebSocket et notre interface web. La commande d'exécution du serveur WebSocket devra être écrite dans le fichier /etc/rc.local pour qu'il s'exécute automatiquement au démarrage du Raspberry.

== Séance 3 ==

=== Partie électronique ===

Nous avons réfléchi au moyen de récupérer la valeur du capteur de température. En effet, la FPGA ne reçoit que des données numériques. Nous avons remarqué en parcourant internet qu'il existait 2 solutions :
la première était d'utiliser un composant qui fait la conversion mais nous ne l'avons pas demandé
la deuxième était de convertie par FPGA le signal.

=== Partie informatique ===

L'objectif de cette dernière séance en terme d'informatique est de réaliser le WebSocket et la page HTML de notre application.
Cette dernière est relativement simple à réaliser dans la mesure où beaucoup d'éléments de la page donnée à titre d'exemple peuvent-être repris pour être adaptés à ce que l'on recherche.

<gallery>
Fichier:Corpshtml.png|Corps du fichier HTML permettant simplement de créer une barre d'insertion, et un bouton valider. (''Cliquez pour agrandir'')
Fichier:Incdec.png|Deux boutons permettant, dans l'optique d'ajouter deux boutons, de décrémenter ou t'incrémenter la valeur de température sélectionnée après un clic sur l'un des deux boutons. (''Cliquez pour agrandir'')
</gallery>

Enfin, la partie la plus délicate du domaine informatique de ce projet aura été de configurer convenablement le WebSocket, de manière à pouvoir recevoir des valeurs depuis le navigateur.
Pour ce faire, nous devons pour commencer démarrer la liaison série à 9600 Bauds, et donc ajouter au préalable toutes les fonctions nécéssaires à l'entretien et l'utilisation de cette liaison série.

<gallery>
Fichier:WebSocket1.png|Déclaration des fonctions utilisées pour l'utilisation de la liaison série. (''Cliquez pour agrandir'')
Fichier:MainWebSocket.png|Démarrage de la liaison série, puis on la garde ouverte avec un while infini. (''Cliquez pour agrandir'')
</gallery>

Enfin, il convient de changer les "cases" au début du WebSocket de manière à récuperer la valeur "in" envoyée via la liaison série.
Dans notre cas, il est seulement utile de changer le cas où on reçoit des informations du navigateur; on rajoute donc simplement les lignes suivantes :

int température;
... (on rentre dans le case LWS_CALLBACK_RECEIVE)
sscanf(in,"%d",&temperature);
if (write(sd,&temperature,sizeof(char))!=1){perror......}

[[Fichier:WebSocket2.png|500px|thumb|center|Partie du code du WebSocket permettant de gérer la réception et l'émission de données. (''Cliquez pour agrandir'')]]

Ce qui nous permet donc de récupérer les valeurs de températures de les renvoyer dans la liaison série vers le système.
Après plusieurs modifications mineures, on obtient bien le résultat escompté avec la carte RedBoard, comme on peut le constater dans la vidéo suivante :
(On rappelle que la LED rouge correspond au ventilateur, et la jaune à la résistance)

[[Média:Video-1466005707.mp4]] (''Cliquez pour lancer la vidéo'')

== Démonstration ==

== Conclusion ==

Bien qu'il ait été compliqué de terminer ce projet, nous pensons avoir rempli tout de même une bonne partie du cahier des charges.
Nous avons acquis de nombreuses compétences dans le domaine informatique : Création de programmes Arduino, Prise en main d'une Raspberry Pi, etc; mais aussi dans le domaine éléctronique comme la programmation de Nanoboard.
Malgré l'échec de la partie éléctronique, nous sommes tout de même satisfait que la partie informatique ait très bien répondu à nos attentes.
De plus, bien que nous ayons cruellement manqué de temps en classe (et d'effectif), nous sommes satisfaits d'avoir pu tester ce qu'il se fait en IMA4.
Enfin, nous sommes satisfaits d'avoir participé à ce type de projet, qui renforce aussi les compétences humaines, comme le travail en équipe, et la réfléxion/concertation en groupe; donnant un aperçu de notre (esperons-le) proche futur d'ingénieur.