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

IMA4 2017/2018 P14

2018-03-20T00:51:31Z

Vdupont1 : /* Lundi 19/03/18 */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
Mercredi 07/02/18 : 4h
|
Mercredi 14/02/18 : 4h
|
Absente (malade)
|
Mercredi 07/03/18 : 4h
|Lundi 12/03/18 : 2h
Mercredi 14/03/18 : 4h
|
|Lundi 19/03/18 : 6h
Mercredi 21/03/18 : ----
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "exiftool" sur chaque Raspberry

* $ sudo apt-get install exiftool

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Observation d'événements particuliers sur des dossiers

* $ apt-get install inotify-tools

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

<pre>#!/bin/sh

# CONFIGURATION

DIR="~/Downloads"
EVENTS="create"

NB_X=1
NB_Y=1
X=0
Y=0

# MAIN

inotifywait -m -e $EVENTS $DIR |
while read file
do

X1=0
Y1=0

X2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1 | awk '{print $1"*(1+X)/$NB_X"}' | bc
Y2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f2 | awk '{print $1"*(1+Y)/$NB_Y"}' | bc

echo "File recieved : $file";
omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 $DIR/$file;
PID=$!;
wait $PID;
rm -f $DIR/$file;
echo "File removed $file";
done

</pre>

==Semaine 5==

===Mercredi 14/02/18===

Récupération du temps de lecture (pour la commande wait)

* exiftool <video> | grep -m 1 "Track Duration" | cut -d' ' -f21 | cut -d':' -fX

X=1 -> heures ; 2 -> minutes ; 3 ; secondes

Début de la conception d'une méthode d'acquisition de la position de l'écran relative aux autres.

Un premier problème est présent pour la détection des coins dans une configuration d'écrans plus ou moins aléatoire

Dans le cas de notre prototype à 4 écrans. Qu'ils soient disposés en carré ou en ligne à l'horizontale ou à la verticale, ça ne pose pas de problème puisqu'il suffit de juger à l'état des (futurs) capteurs disposé cependant dans le cas où l'on supprime un écran, on se retrouve avec des incohérences

==Semaine 6==

absente pour maladie toute la semaine

==Semaine 7==

Jusqu'à présent nous nous sommes surtout intéressés à la partie lecture du flux vidéo (fichier jusqu'à présent) et nous alors donc nous orienter sur la partie essentielle, le streaming de la R-pi maîtresse.

Remarque : La R-pi maîtresse sera dotée d'une caméra afin de pouvoir effectuer la détection des écrans via un traitement d'image.

Le concept est simple, la R-pi envoie un signal aux autres qui doivent afficher un identifiant qui est sous la forme d'une image de 4 carrés de couleurs.
Ensuite elle prend une photo des écrans puis après un traitement d'image elle peut ensuite attribuer les fichiers de configuration aux R-pi correspondantes pour les scripts de lecture

Pour le moment, seul le streaming par VLC sur la maîtresse et la lecture sous omxplayer sur la partie visualisation fonctionne mais souffre d'une latence particulièrement élevée (rappel: vlc consomme 97%+ de la raspberry).

==Semaine 8==

===Lundi 12/03/18===

* Problème avec la carte SD de la R-pi 1 théoriquement résolu en copiant via "dd if=<input_file> of=<output_file>"

* Début des recherches sur le traitement d'image par une raspberry utilisant une caméra.

OpenCV semble proposer plusieurs solution possibles qui sont à exploiter

Sources:

- Vidéo de présentation d'un projet de reconnaissance de formes colorées [https://www.youtube.com/watch?v=uV7mLcYoaV8]

- Détermination de la couleur d'un objet avec OpenCV [https://www.pyimagesearch.com/2016/02/15/determining-object-color-with-opencv/]

- Shape Detection avec OpenCV [https://www.pyimagesearch.com/2016/02/08/opencv-shape-detection/]

* Solution à examiner pour la gestion d'un stream par une R-pi puis lu par une R-pi via omxplayer [https://stackoverflow.com/questions/25498765/how-to-play-mjpeg-stream-with-omxplayer]

===Mercredi 14/03/18===

* Installation d'OpenCV sur la R-pi maîtresse suivant le tutoriel [https://www.pyimagesearch.com/2016/04/18/install-guide-raspberry-pi-3-raspbian-jessie-opencv-3/]

Note : Lors de l'installation le nom de l'environnement du tutoriel est "cv" pour les deux exemples (python2 et python3) or nous avons déclaré "cv2" pour python2 ET "cv3" pour python3

-> actuellement bloquée au point du make -j4 la compilation plante à environ 24-25% sur une erreur (même chose avec la commande make pour n'utiliser qu'un coeur de la R-pi)

* Création d'un serveur de stream pour la R-pi maîtresse [https://github.com/cncjs/cncjs/wiki/Setup-Guide:-Raspberry-Pi-%7C-MJPEG-Streamer-Install-&-Setup-&-FFMpeg-Recording]

-> Le système est installé sur la R-pi maîtresse mais n'arrive pas à se lancer pour le moment -> en recherche de solution pour ce problème

==Semaine 9==

===Lundi 19/03/18===

* Compilation d'OpenCV débloquée [https://stackoverflow.com/questions/40262928/error-compiling-opencv-fatal-error-stdlib-h-no-such-file-or-directory]

Réinstallation effectuée proprement en raison d'un problème avec stdlib.h dans les fichiers précompilés d'où l'ajout de la commande

>>> -DENABLE_PRECOMPILED_HEADERS=OFF

à la suite du cmake qui est à présent
<pre>
$ cd ~/opencv-3.1.0/
$ mkdir build
$ cd build
$ cmake -D CMAKE_BUILD_TYPE=RELEASE \
-D CMAKE_INSTALL_PREFIX=/usr/local \
-D INSTALL_PYTHON_EXAMPLES=ON \
-D OPENCV_EXTRA_MODULES_PATH=~/opencv_contrib-3.1.0/modules \
-D BUILD_EXAMPLES=ON .. \
-DENABLE_PRECOMPILED_HEADERS=OFF

</pre>

* Réinstallation complète du serveur de stream indiqué au tutoriel : [https://github.com/cncjs/cncjs/wiki/Setup-Guide:-Raspberry-Pi-%7C-MJPEG-Streamer-Install-&-Setup-&-FFMpeg-Recording]

Le serveur est fonctionnel (testé en local uniquement) localhost:8081/steam.html conformément au instructions.

L'une des raisons du non fonctionnement était que /dev/video0 n'était pas disponible malgré le fait qu'une caméra était présente sur la raspberry or une webcam branchée en USB permet l'apparition de /dev/video1 qui a été utilisée pour le test.

==Semaine 10==

=Documents Rendus=

IMA4 2017/2018 P14

2018-03-19T14:37:07Z

Vdupont1 : /* Lundi 19/03/18 */

IMA4 2017/2018 P14

2018-03-19T14:36:55Z

Vdupont1 : /* Lundi 19/03/18 */

IMA4 2017/2018 P14

2018-03-19T14:34:27Z

Vdupont1 : /* Feuille d'heures */

IMA4 2017/2018 P14

2018-03-19T13:38:24Z

Vdupont1 : /* Semaine 9 */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
Mercredi 07/02/18 : 4h
|
Mercredi 14/02/18 : 4h
|
Absente (malade)
|
Mercredi 07/03/18 : 4h
|Lundi 12/03/18 : 2h
Mercredi 14/03/18 : 4h
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "exiftool" sur chaque Raspberry

* $ sudo apt-get install exiftool

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Observation d'événements particuliers sur des dossiers

* $ apt-get install inotify-tools

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

<pre>#!/bin/sh

# CONFIGURATION

DIR="~/Downloads"
EVENTS="create"

NB_X=1
NB_Y=1
X=0
Y=0

# MAIN

inotifywait -m -e $EVENTS $DIR |
while read file
do

X1=0
Y1=0

X2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1 | awk '{print $1"*(1+X)/$NB_X"}' | bc
Y2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f2 | awk '{print $1"*(1+Y)/$NB_Y"}' | bc

echo "File recieved : $file";
omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 $DIR/$file;
PID=$!;
wait $PID;
rm -f $DIR/$file;
echo "File removed $file";
done

</pre>

==Semaine 5==

===Mercredi 14/02/18===

Récupération du temps de lecture (pour la commande wait)

* exiftool <video> | grep -m 1 "Track Duration" | cut -d' ' -f21 | cut -d':' -fX

X=1 -> heures ; 2 -> minutes ; 3 ; secondes

Début de la conception d'une méthode d'acquisition de la position de l'écran relative aux autres.

Un premier problème est présent pour la détection des coins dans une configuration d'écrans plus ou moins aléatoire

Dans le cas de notre prototype à 4 écrans. Qu'ils soient disposés en carré ou en ligne à l'horizontale ou à la verticale, ça ne pose pas de problème puisqu'il suffit de juger à l'état des (futurs) capteurs disposé cependant dans le cas où l'on supprime un écran, on se retrouve avec des incohérences

==Semaine 6==

absente pour maladie toute la semaine

==Semaine 7==

Jusqu'à présent nous nous sommes surtout intéressés à la partie lecture du flux vidéo (fichier jusqu'à présent) et nous alors donc nous orienter sur la partie essentielle, le streaming de la R-pi maîtresse.

Remarque : La R-pi maîtresse sera dotée d'une caméra afin de pouvoir effectuer la détection des écrans via un traitement d'image.

Le concept est simple, la R-pi envoie un signal aux autres qui doivent afficher un identifiant qui est sous la forme d'une image de 4 carrés de couleurs.
Ensuite elle prend une photo des écrans puis après un traitement d'image elle peut ensuite attribuer les fichiers de configuration aux R-pi correspondantes pour les scripts de lecture

Pour le moment, seul le streaming par VLC sur la maîtresse et la lecture sous omxplayer sur la partie visualisation fonctionne mais souffre d'une latence particulièrement élevée (rappel: vlc consomme 97%+ de la raspberry).

==Semaine 8==

===Lundi 12/03/18===

* Problème avec la carte SD de la R-pi 1 théoriquement résolu en copiant via "dd if=<input_file> of=<output_file>"

* Début des recherches sur le traitement d'image par une raspberry utilisant une caméra.

OpenCV semble proposer plusieurs solution possibles qui sont à exploiter

Sources:

- Vidéo de présentation d'un projet de reconnaissance de formes colorées [https://www.youtube.com/watch?v=uV7mLcYoaV8]

- Détermination de la couleur d'un objet avec OpenCV [https://www.pyimagesearch.com/2016/02/15/determining-object-color-with-opencv/]

- Shape Detection avec OpenCV [https://www.pyimagesearch.com/2016/02/08/opencv-shape-detection/]

* Solution à examiner pour la gestion d'un stream par une R-pi puis lu par une R-pi via omxplayer [https://stackoverflow.com/questions/25498765/how-to-play-mjpeg-stream-with-omxplayer]

===Mercredi 14/03/18===

* Installation d'OpenCV sur la R-pi maîtresse suivant le tutoriel [https://www.pyimagesearch.com/2016/04/18/install-guide-raspberry-pi-3-raspbian-jessie-opencv-3/]

Note : Lors de l'installation le nom de l'environnement du tutoriel est "cv" pour les deux exemples (python2 et python3) or nous avons déclaré "cv2" pour python2 ET "cv3" pour python3

-> actuellement bloquée au point du make -j4 la compilation plante à environ 24-25% sur une erreur (même chose avec la commande make pour n'utiliser qu'un coeur de la R-pi)

* Création d'un serveur de stream pour la R-pi maîtresse [https://github.com/cncjs/cncjs/wiki/Setup-Guide:-Raspberry-Pi-%7C-MJPEG-Streamer-Install-&-Setup-&-FFMpeg-Recording]

-> Le système est installé sur la R-pi maîtresse mais n'arrive pas à se lancer pour le moment -> en recherche de solution pour ce problème

==Semaine 9==

===Lundi 19/03/18===

* Compilation d'OpenCV débloquée [https://stackoverflow.com/questions/40262928/error-compiling-opencv-fatal-error-stdlib-h-no-such-file-or-directory]

==Semaine 10==

=Documents Rendus=

IMA4 2017/2018 P14

2018-03-19T13:38:11Z

Vdupont1 : /* Semaine 9 */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
Mercredi 07/02/18 : 4h
|
Mercredi 14/02/18 : 4h
|
Absente (malade)
|
Mercredi 07/03/18 : 4h
|Lundi 12/03/18 : 2h
Mercredi 14/03/18 : 4h
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "exiftool" sur chaque Raspberry

* $ sudo apt-get install exiftool

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Observation d'événements particuliers sur des dossiers

* $ apt-get install inotify-tools

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

<pre>#!/bin/sh

# CONFIGURATION

DIR="~/Downloads"
EVENTS="create"

NB_X=1
NB_Y=1
X=0
Y=0

# MAIN

inotifywait -m -e $EVENTS $DIR |
while read file
do

X1=0
Y1=0

X2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1 | awk '{print $1"*(1+X)/$NB_X"}' | bc
Y2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f2 | awk '{print $1"*(1+Y)/$NB_Y"}' | bc

echo "File recieved : $file";
omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 $DIR/$file;
PID=$!;
wait $PID;
rm -f $DIR/$file;
echo "File removed $file";
done

</pre>

==Semaine 5==

===Mercredi 14/02/18===

Récupération du temps de lecture (pour la commande wait)

* exiftool <video> | grep -m 1 "Track Duration" | cut -d' ' -f21 | cut -d':' -fX

X=1 -> heures ; 2 -> minutes ; 3 ; secondes

Début de la conception d'une méthode d'acquisition de la position de l'écran relative aux autres.

Un premier problème est présent pour la détection des coins dans une configuration d'écrans plus ou moins aléatoire

Dans le cas de notre prototype à 4 écrans. Qu'ils soient disposés en carré ou en ligne à l'horizontale ou à la verticale, ça ne pose pas de problème puisqu'il suffit de juger à l'état des (futurs) capteurs disposé cependant dans le cas où l'on supprime un écran, on se retrouve avec des incohérences

==Semaine 6==

absente pour maladie toute la semaine

==Semaine 7==

Jusqu'à présent nous nous sommes surtout intéressés à la partie lecture du flux vidéo (fichier jusqu'à présent) et nous alors donc nous orienter sur la partie essentielle, le streaming de la R-pi maîtresse.

Remarque : La R-pi maîtresse sera dotée d'une caméra afin de pouvoir effectuer la détection des écrans via un traitement d'image.

Le concept est simple, la R-pi envoie un signal aux autres qui doivent afficher un identifiant qui est sous la forme d'une image de 4 carrés de couleurs.
Ensuite elle prend une photo des écrans puis après un traitement d'image elle peut ensuite attribuer les fichiers de configuration aux R-pi correspondantes pour les scripts de lecture

Pour le moment, seul le streaming par VLC sur la maîtresse et la lecture sous omxplayer sur la partie visualisation fonctionne mais souffre d'une latence particulièrement élevée (rappel: vlc consomme 97%+ de la raspberry).

==Semaine 8==

===Lundi 12/03/18===

* Problème avec la carte SD de la R-pi 1 théoriquement résolu en copiant via "dd if=<input_file> of=<output_file>"

* Début des recherches sur le traitement d'image par une raspberry utilisant une caméra.

OpenCV semble proposer plusieurs solution possibles qui sont à exploiter

Sources:

- Vidéo de présentation d'un projet de reconnaissance de formes colorées [https://www.youtube.com/watch?v=uV7mLcYoaV8]

- Détermination de la couleur d'un objet avec OpenCV [https://www.pyimagesearch.com/2016/02/15/determining-object-color-with-opencv/]

- Shape Detection avec OpenCV [https://www.pyimagesearch.com/2016/02/08/opencv-shape-detection/]

* Solution à examiner pour la gestion d'un stream par une R-pi puis lu par une R-pi via omxplayer [https://stackoverflow.com/questions/25498765/how-to-play-mjpeg-stream-with-omxplayer]

===Mercredi 14/03/18===

* Installation d'OpenCV sur la R-pi maîtresse suivant le tutoriel [https://www.pyimagesearch.com/2016/04/18/install-guide-raspberry-pi-3-raspbian-jessie-opencv-3/]

Note : Lors de l'installation le nom de l'environnement du tutoriel est "cv" pour les deux exemples (python2 et python3) or nous avons déclaré "cv2" pour python2 ET "cv3" pour python3

-> actuellement bloquée au point du make -j4 la compilation plante à environ 24-25% sur une erreur (même chose avec la commande make pour n'utiliser qu'un coeur de la R-pi)

* Création d'un serveur de stream pour la R-pi maîtresse [https://github.com/cncjs/cncjs/wiki/Setup-Guide:-Raspberry-Pi-%7C-MJPEG-Streamer-Install-&-Setup-&-FFMpeg-Recording]

-> Le système est installé sur la R-pi maîtresse mais n'arrive pas à se lancer pour le moment -> en recherche de solution pour ce problème

==Semaine 9==

Lundi 19/03/18

* Compilation d'OpenCV débloquée [https://stackoverflow.com/questions/40262928/error-compiling-opencv-fatal-error-stdlib-h-no-such-file-or-directory]

==Semaine 10==

=Documents Rendus=

Discussion:Projets IMA4 SC & SA 2017/2018

2018-02-21T14:24:46Z

Vdupont1 : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
| Si le contenu du Wiki reflète la quantité de travail fourni, c'est inquiétant.
|
|
|
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
| Illustrez votre Wiki avec des schémas ou des photos de votre montage. Décrivez mieux votre plateforme de test et les résultats obtenus. Essayez de corriger les problèmes de français.
|
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
| Vous devriez avoir quelques éléments sur la réalisation. Complétez votre Wiki.
|
|
|
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
| Un effort de documentation mais illustrez par des schémas, des pages de l'application et des tests.
|
|
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
| Très bonne description de l'avancé du projet. N'hésitez pas à solliciter votre encadrant direct en cas de blocage !
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
| Très bonne description de l'avancé du projet. Faites un effort de formatage du texte (par exemple en utilisant des sous-titres plutôt que de souligner des lignes).
|
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
| Une bonne description de l'avancé du projet.
|
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
| Très bonne description de l'avancé du projet. Wiki agréable à lire.
|
|
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
| Une bonne description de l'avancé du projet. Essayez de mieux formater votre texte pour une meilleure facilité de lecture.
|
|
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
| Rien sur l'avancé du projet au 18/02/2018. Wiki mis à jour en catastrophe le 19/02/2018. Peu d'informations, seul le routage d'une carte semble avoir été entrepris.
|
|
|
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
| Bonne description du travail. Cinq séances pour faire chauffer une résistance, n'est-ce pas trop ?
|
|
|
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
| Une bonne description de l'avancé du projet. Projet encore dans la phase de prototypage. Comment vous comptez recevoir une carte SIM ?
|
|
|
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
| Le travail est a peu près décrit mais la page Wiki ressemble a un brouillon.
|
|
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
| Le travail avec le prototype pilote de LEDs est très bien décrit et de façon agréable à lire. Par contre le schéma du futur circuit est très mal engagé. Il faut commencer par faire un schéma plus précis du collier.
|
|
|
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
| Rien sur l'avancé du projet. Aucun travail ?
|
|
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Compte-rendu du travail très lapidaire et parfois illisible à cause des coquilles. Le Wiki ne donne pas l'impression que le projet avance.
|
|
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
| Compte-rendu non à jour au 18/02/2018 alors que la feuille d'heures est à jour. Le Wiki manque d'illustration, par exemple donnez le schéma du circuit. Des informations sur la carte en gestation.
|
|
|
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
| Impossible de connaître l'avancé du projet à la lecture du Wiki. N'êtes-vous pas entrain de vous perdre dans vos problèmes avec FreeRTOS ?
|
|
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
| Bonne description du travail. Votre Wiki manque d'illustrations sur un sujet qui le permet.
|
|
|
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Attention quand vous dites qu'un ATMega328p n'a pas assez de sorties pour commander 8 oscillateurs, il dispose tout de même de plus de 20 E/S.
|
|
|
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
| Description du travail correct, des illustrations. Essayez de formater avec la syntaxe Wiki.
|
|
|
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
| Le travail effectué est décrit. Un nombre de coquilles non acceptable, la lecture en devient difficile. Utilisez la syntaxe de formatage du Wiki.
|
|
|
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
| Description du travail un peu rapide (DNS leak quesako ?). Rédaction en cours au moment de la lecture du Wiki.Effort de rédaction entre le 18/02/2018 et le 19/02/2018. Il manque des sections mais le travail effectué devient lisible.
|
|
|
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Il est possible de mettre une copie d'écran de l'application de plus. Pas la peine de vous tirer dans les pattes.
|
|
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
| Très bonne description du travail. Des illustrations mais il pourrait y avoir des photos du système robotino / kinect. Feuille d'heure étrange.
|
|
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
| Compte-rendu rapide du travail. Ce compte-rendu est inquiétant. Il ne semble y avoir aucun résultat depuis le début du projet. Un module a été abandonné sans que le module en question n'ait été décrit ou que la raison de l'abandon ait été précisé. Attention votre projet est en voie d'échec.
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
| Le robot centaure est en plus mauvais état maintenant qu'au début du projet. Vous semblez avoir une nouvelle fois abandonné votre projet. Des ajouts mineurs au Wiki le 19/02/2018.
|
|
|
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
| Un Wiki incomplet alors que la feuille d'heures est actualisée. Vous semblez toujours bloqués sur les problèmes d'étalonnage !
|
|
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
| Très peu d'illustrations. Texte mal formaté et avec des coquilles intolérable à ce niveau d'étude. Le compte-rendu donne l'impression d'une méthode de travail très brouillonne.
|
|
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
| Tout simplement parfait ! Bien illustré, bien rédigé, le travail est très bien décrit. Presque à jour. Vous n'aviez pas des cartes à faire fabriquer à l'extérieur ?
|
|
|
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
|Exceptionnel ! Très illustré, bien rédigé, le travail de recherche est très bien décrit. Je ne suis pas un fan de la mise en gras d'un quart du texte et la syntaxe Wiki n'est pas vraiment utilisée mais c'est du détail?
|
|
|
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
| Rien sur l'avancé du projet. Projet en échec ?
|
|
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
| Projet en échec constaté.
|
|
|
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304
|E304
|E304
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|E301
|E306
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|C008
|C008
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|E301
|E301 puis B309 puis B207
|E301
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gosse
| E306
| E306
| E306
| E306
| E306
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
| E301 
| E301 
| E301 
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
| E301
| E301
| E301
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| E301
| C201
| C201
| B207
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|E304
|E304
|Absence Maladie
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle (E304 - A305)
| E301
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
| E304
| E304
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|E304
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
| E304
| E304

|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
| E304
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|E303
|B309 puis B207
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
| C203/E306
| E306/E304
| E304

|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
| E306 - C201
| E304
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
| E306
| E306
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
| C205
| C205/E301
| C205/E301
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
| E306
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
| E306
| E306
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
| E306
| E306
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|E304/E302
|E306/E302
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle (E301)
| E304 + 17h réunion C00X
| C205
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle (INRIA)
| E301
| E301 puis E304
| E301
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106 Pas de salle Absentes 
|C008
|C008
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| (Pas de salle) E303
|E303
|E303
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury/ Prud'Homme Geoffrey
| fabricarium
| fabricarium puis Hors Polytech
| E304
| E301
| Carval E306 - Preud'homme E301
| E301
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
| E301
| E302
|-
| PP1 [[IMA4 2017/2018 PP1|Robot hexapode pour escalier]]
| Eduardo Gomez
|C201
|C201
|C201
|Fabricarium
|Fabricarium
|C201
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

IMA4 2017/2018 P14

2018-02-15T09:31:19Z

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

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
Mercredi 07/02/18 : 4h
|
Mercredi 14/02/18 : 4h
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "exiftool" sur chaque Raspberry

* $ sudo apt-get install exiftool

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Observation d'événements particuliers sur des dossiers

* $ apt-get install inotify-tools

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

<pre>#!/bin/sh

# CONFIGURATION

DIR="~/Downloads"
EVENTS="create"

NB_X=1
NB_Y=1
X=0
Y=0

# MAIN

inotifywait -m -e $EVENTS $DIR |
while read file
do

X1=0
Y1=0

X2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1 | awk '{print $1"*(1+X)/$NB_X"}' | bc
Y2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f2 | awk '{print $1"*(1+Y)/$NB_Y"}' | bc

echo "File recieved : $file";
omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 $DIR/$file;
PID=$!;
wait $PID;
rm -f $DIR/$file;
echo "File removed $file";
done

</pre>

==Semaine 5==

===Mercredi 14/02/18===

Récupération du temps de lecture (pour la commande wait)

* exiftool <video> | grep -m 1 "Track Duration" | cut -d' ' -f21 | cut -d':' -fX

X=1 -> heures ; 2 -> minutes ; 3 ; secondes

Début de la conception d'une méthode d'acquisition de la position de l'écran relative aux autres.

Un premier problème est présent pour la détection des coins dans une configuration d'écrans plus ou moins aléatoire

Dans le cas de notre prototype à 4 écrans. Qu'ils soient disposés en carré ou en ligne à l'horizontale ou à la verticale, ça ne pose pas de problème puisqu'il suffit de juger à l'état des (futurs) capteurs disposé cependant dans le cas où l'on supprime un écran, on se retrouve avec des incohérences

==Semaine 6==

==Semaine 7==

==Semaine 8==

==Semaine 9==

==Semaine 10==

=Documents Rendus=

Discussion:Projets IMA4 SC & SA 2017/2018

2018-02-14T18:03:51Z

Vdupont1 : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
|
|
|
|
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
|
|
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
|
|
|
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
|
|
|
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
|
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
|
|
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
|
|
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
|
|
|
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
|
|
|
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
|
|
|
|
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
|
|
|
|
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
|
|
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
|
|
|
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
|
|
|
|
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
|
|
|
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
|
|
|
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
|
|
|
|
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
|
|
|
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
|
|
|
|
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
|
|
|
|
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
|
|
|
|
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
|
|
|
|
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
|
|
|
|
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
|
|
|
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
|
|
|
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
|
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
|
|
|
|
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
|
|
|
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
|
|
|
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
|
|
|
|
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
|
|
|
|
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
|
|
|
|
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
|
|
|
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
|
|
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304
|E304
|E304
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|E301
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|C008
|C008
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|E301
|E301 puis B309 puis B207
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gosse
| E306
| E306
| E306
| E306
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
| E301 
| E301 
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
| E301
| E301
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| E301
| C201
| C201
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|E304
|E304
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle (E304 - A305)
| E301
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
| E304
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
| E304

|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|E303
|B309 puis B207
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
| C203/E306
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
| E306 - C201
| E304
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
| E306
| E306
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
| C205
| C205/E301
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
| E306

|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
| E306
| E306
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|E304/E302
|E306/E302
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle (E301)
| E304 + 17h réunion C00X
| C205
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle (INRIA)
| E301
| E301 puis E304
|
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106 Pas de salle Absentes 
|C008
|C008
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| (Pas de salle) E303
|E303
|E303
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury/ Prud'Homme Geoffrey
| fabricarium
| fabricarium puis Hors Polytech
| E304
| E301
| Carval E306 - Preud'homme E301
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
| E301
| E302
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

IMA4 2017/2018 P14

2018-02-14T18:03:19Z

Vdupont1 : /* Réalisation du Projet */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

* 16 [pack 25] Capteur de contact (1 par côté) [https://fr.rs-online.com/web/p/capteurs-proximites/7985273/] '''Envisagés pour la seconde partie du projet mais non validés pour le moment !'''

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
Mercredi 07/02/18 : 4h
|
Mercredi 14/02/18 : 4h
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "exiftool" sur chaque Raspberry

* $ sudo apt-get install exiftool

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Observation d'événements particuliers sur des dossiers

* $ apt-get install inotify-tools

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

<pre>#!/bin/sh

# CONFIGURATION

DIR="~/Downloads"
EVENTS="create"

NB_X=1
NB_Y=1
X=0
Y=0

# MAIN

inotifywait -m -e $EVENTS $DIR |
while read file
do

X1=0
Y1=0

X2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1 | awk '{print $1"*(1+X)/$NB_X"}' | bc
Y2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f2 | awk '{print $1"*(1+Y)/$NB_Y"}' | bc

echo "File recieved : $file";
omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 $DIR/$file;
PID=$!;
wait $PID;
rm -f $DIR/$file;
echo "File removed $file";
done

</pre>

==Semaine 5==

===Mercredi 14/02/18===

Récupération du temps de lecture (pour la commande wait)

* exiftool <video> | grep -m 1 "Track Duration" | cut -d' ' -f21 | cut -d':' -fX

X=1 -> heures ; 2 -> minutes ; 3 ; secondes

Début de la conception d'une méthode d'acquisition de la position de l'écran relative aux autres.

Un premier problème est présent pour la détection des coins dans une configuration d'écrans plus ou moins aléatoire

Dans le cas de notre prototype à 4 écrans. Qu'ils soient disposés en carré ou en ligne à l'horizontale ou à la verticale, ça ne pose pas de problème puisqu'il suffit de juger à l'état des (futurs) capteurs disposé cependant dans le cas où l'on supprime un écran, on se retrouve avec des incohérences

==Semaine 6==

==Semaine 7==

==Semaine 8==

==Semaine 9==

==Semaine 10==

=Documents Rendus=

IMA4 2017/2018 P14

2018-02-14T18:03:03Z

Vdupont1 : /* Feuille d'heures */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

* 16 [pack 25] Capteur de contact (1 par côté) [https://fr.rs-online.com/web/p/capteurs-proximites/7985273/] '''Envisagés pour la seconde partie du projet mais non validés pour le moment !'''

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
Mercredi 07/02/18 : 4h
|
Mercredi 14/02/18 : 4h
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "exiftool" sur chaque Raspberry

* $ sudo apt-get install exiftool

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Observation d'événements particuliers sur des dossiers

* $ apt-get install inotify-tools

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

<pre>#!/bin/sh

# CONFIGURATION

DIR="~/Downloads"
EVENTS="create"

NB_X=1
NB_Y=1
X=0
Y=0

# MAIN

inotifywait -m -e $EVENTS $DIR |
while read file
do

X1=0
Y1=0

X2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1 | awk '{print $1"*(1+X)/$NB_X"}' | bc
Y2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f2 | awk '{print $1"*(1+Y)/$NB_Y"}' | bc

echo "File recieved : $file";
omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 $DIR/$file;
PID=$!;
wait $PID;
rm -f $DIR/$file;
echo "File removed $file";
done

</pre>

==Semaine 5==

===Mercredi 13/02/18===

Récupération du temps de lecture (pour la commande wait)

* exiftool <video> | grep -m 1 "Track Duration" | cut -d' ' -f21 | cut -d':' -fX

X=1 -> heures ; 2 -> minutes ; 3 ; secondes

Début de la conception d'une méthode d'acquisition de la position de l'écran relative aux autres.

Un premier problème est présent pour la détection des coins dans une configuration d'écrans plus ou moins aléatoire

Dans le cas de notre prototype à 4 écrans. Qu'ils soient disposés en carré ou en ligne à l'horizontale ou à la verticale, ça ne pose pas de problème puisqu'il suffit de juger à l'état des (futurs) capteurs disposé cependant dans le cas où l'on supprime un écran, on se retrouve avec des incohérences

==Semaine 6==

==Semaine 7==

==Semaine 8==

==Semaine 9==

==Semaine 10==

=Documents Rendus=

IMA4 2017/2018 P14

2018-02-14T18:02:49Z

Vdupont1 : /* Feuille d'heures */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

* 16 [pack 25] Capteur de contact (1 par côté) [https://fr.rs-online.com/web/p/capteurs-proximites/7985273/] '''Envisagés pour la seconde partie du projet mais non validés pour le moment !'''

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
Mercredi 07/02/18 : 4h
|
Mercredi 13/02/18 : 4h
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "exiftool" sur chaque Raspberry

* $ sudo apt-get install exiftool

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Observation d'événements particuliers sur des dossiers

* $ apt-get install inotify-tools

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

<pre>#!/bin/sh

# CONFIGURATION

DIR="~/Downloads"
EVENTS="create"

NB_X=1
NB_Y=1
X=0
Y=0

# MAIN

inotifywait -m -e $EVENTS $DIR |
while read file
do

X1=0
Y1=0

X2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1 | awk '{print $1"*(1+X)/$NB_X"}' | bc
Y2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f2 | awk '{print $1"*(1+Y)/$NB_Y"}' | bc

echo "File recieved : $file";
omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 $DIR/$file;
PID=$!;
wait $PID;
rm -f $DIR/$file;
echo "File removed $file";
done

</pre>

==Semaine 5==

===Mercredi 13/02/18===

Récupération du temps de lecture (pour la commande wait)

* exiftool <video> | grep -m 1 "Track Duration" | cut -d' ' -f21 | cut -d':' -fX

X=1 -> heures ; 2 -> minutes ; 3 ; secondes

Début de la conception d'une méthode d'acquisition de la position de l'écran relative aux autres.

Un premier problème est présent pour la détection des coins dans une configuration d'écrans plus ou moins aléatoire

Dans le cas de notre prototype à 4 écrans. Qu'ils soient disposés en carré ou en ligne à l'horizontale ou à la verticale, ça ne pose pas de problème puisqu'il suffit de juger à l'état des (futurs) capteurs disposé cependant dans le cas où l'on supprime un écran, on se retrouve avec des incohérences

==Semaine 6==

==Semaine 7==

==Semaine 8==

==Semaine 9==

==Semaine 10==

=Documents Rendus=

IMA4 2017/2018 P14

2018-02-14T18:02:29Z

Vdupont1 : /* Réalisation du Projet */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

* 16 [pack 25] Capteur de contact (1 par côté) [https://fr.rs-online.com/web/p/capteurs-proximites/7985273/] '''Envisagés pour la seconde partie du projet mais non validés pour le moment !'''

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
Mercredi 07/02/18 : 4h
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "exiftool" sur chaque Raspberry

* $ sudo apt-get install exiftool

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Observation d'événements particuliers sur des dossiers

* $ apt-get install inotify-tools

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

<pre>#!/bin/sh

# CONFIGURATION

DIR="~/Downloads"
EVENTS="create"

NB_X=1
NB_Y=1
X=0
Y=0

# MAIN

inotifywait -m -e $EVENTS $DIR |
while read file
do

X1=0
Y1=0

X2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1 | awk '{print $1"*(1+X)/$NB_X"}' | bc
Y2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f2 | awk '{print $1"*(1+Y)/$NB_Y"}' | bc

echo "File recieved : $file";
omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 $DIR/$file;
PID=$!;
wait $PID;
rm -f $DIR/$file;
echo "File removed $file";
done

</pre>

==Semaine 5==

===Mercredi 13/02/18===

Récupération du temps de lecture (pour la commande wait)

* exiftool <video> | grep -m 1 "Track Duration" | cut -d' ' -f21 | cut -d':' -fX

X=1 -> heures ; 2 -> minutes ; 3 ; secondes

Début de la conception d'une méthode d'acquisition de la position de l'écran relative aux autres.

Un premier problème est présent pour la détection des coins dans une configuration d'écrans plus ou moins aléatoire

Dans le cas de notre prototype à 4 écrans. Qu'ils soient disposés en carré ou en ligne à l'horizontale ou à la verticale, ça ne pose pas de problème puisqu'il suffit de juger à l'état des (futurs) capteurs disposé cependant dans le cas où l'on supprime un écran, on se retrouve avec des incohérences

==Semaine 6==

==Semaine 7==

==Semaine 8==

==Semaine 9==

==Semaine 10==

=Documents Rendus=

IMA4 2017/2018 P14

2018-02-14T14:25:22Z

Vdupont1 : /* Semaine 5 */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

* 16 [pack 25] Capteur de contact (1 par côté) [https://fr.rs-online.com/web/p/capteurs-proximites/7985273/] '''Envisagés pour la seconde partie du projet mais non validés pour le moment !'''

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
Mercredi 07/02/18 : 4h
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "exiftool" sur chaque Raspberry

* $ sudo apt-get install exiftool

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Observation d'événements particuliers sur des dossiers

* $ apt-get install inotify-tools

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

<pre>#!/bin/sh

# CONFIGURATION

DIR="/home/pifou/Downloads"
EVENTS="create"

NB_X=1
NB_Y=1

# MAIN

inotifywait -m -e $EVENTS $DIR |
while read file
do

X1=0
Y1=0

X2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1 | awk '{print $1"/$NB_X"}' | bc
Y2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f2 | awk '{print $1"/$NB_Y"}' | bc

echo "File recieved : $file";
omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 $DIR/$file;
PID=$!;
wait $PID;
rm -f $DIR/$file;
echo "File removed $file";
done

</pre>

==Semaine 5==

Récupération du temps de lecture (pour la commande wait)

* exiftool <video> | grep -m 1 "Track Duration" | cut -d' ' -f21 | cut -d':' -fX

X=1 -> heures ; 2 -> minutes ; 3 ; secondes

==Semaine 6==

==Semaine 7==

==Semaine 8==

==Semaine 9==

==Semaine 10==

=Documents Rendus=

IMA4 2017/2018 P14

2018-02-07T19:37:25Z

Vdupont1 : /* Feuille d'heures */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

* 16 [pack 25] Capteur de contact (1 par côté) [https://fr.rs-online.com/web/p/capteurs-proximites/7985273/] '''Envisagés pour la seconde partie du projet mais non validés pour le moment !'''

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
Mercredi 07/02/18 : 4h
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "exiftool" sur chaque Raspberry

* $ sudo apt-get install exiftool

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Observation d'événements particuliers sur des dossiers

* $ apt-get install inotify-tools

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

<pre>#!/bin/sh

# CONFIGURATION

DIR="/home/pifou/Downloads"
EVENTS="create"

NB_X=1
NB_Y=1

# MAIN

inotifywait -m -e $EVENTS $DIR |
while read file
do

X1=0
Y1=0

X2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1 | awk '{print $1"/$NB_X"}' | bc
Y2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f2 | awk '{print $1"/$NB_Y"}' | bc

echo "File recieved : $file";
omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 $DIR/$file;
PID=$!;
wait $PID;
rm -f $DIR/$file;
echo "File removed $file";
done

</pre>

==Semaine 5==

==Semaine 6==

==Semaine 7==

==Semaine 8==

==Semaine 9==

==Semaine 10==

=Documents Rendus=

IMA4 2017/2018 P14

2018-02-07T17:44:01Z

Vdupont1 : /* Mercredi 07/02/18 */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

* 16 [pack 25] Capteur de contact (1 par côté) [https://fr.rs-online.com/web/p/capteurs-proximites/7985273/] '''Envisagés pour la seconde partie du projet mais non validés pour le moment !'''

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "exiftool" sur chaque Raspberry

* $ sudo apt-get install exiftool

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Observation d'événements particuliers sur des dossiers

* $ apt-get install inotify-tools

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

<pre>#!/bin/sh

# CONFIGURATION

DIR="/home/pifou/Downloads"
EVENTS="create"

NB_X=1
NB_Y=1

# MAIN

inotifywait -m -e $EVENTS $DIR |
while read file
do

X1=0
Y1=0

X2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1 | awk '{print $1"/$NB_X"}' | bc
Y2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f2 | awk '{print $1"/$NB_Y"}' | bc

echo "File recieved : $file";
omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 $DIR/$file;
PID=$!;
wait $PID;
rm -f $DIR/$file;
echo "File removed $file";
done

</pre>

==Semaine 5==

==Semaine 6==

==Semaine 7==

==Semaine 8==

==Semaine 9==

==Semaine 10==

=Documents Rendus=

IMA4 2017/2018 P14

2018-02-07T17:43:20Z

Vdupont1 : /* Mercredi 07/02/18 */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

* 16 [pack 25] Capteur de contact (1 par côté) [https://fr.rs-online.com/web/p/capteurs-proximites/7985273/] '''Envisagés pour la seconde partie du projet mais non validés pour le moment !'''

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "sudo apt-get install exiftool" sur chaque Raspberry

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Observation d'événements particuliers sur des dossiers

* $ apt-get install inotify-tools

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

<pre>#!/bin/sh

# CONFIGURATION

DIR="/home/pifou/Downloads"
EVENTS="create"

NB_X=1
NB_Y=1

# MAIN

inotifywait -m -e $EVENTS $DIR |
while read file
do

X1=0
Y1=0

X2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1 | awk '{print $1"/$NB_X"}' | bc
Y2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f2 | awk '{print $1"/$NB_Y"}' | bc

echo "File recieved : $file";
omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 $DIR/$file;
PID=$!;
wait $PID;
rm -f $DIR/$file;
echo "File removed $file";
done

</pre>

==Semaine 5==

==Semaine 6==

==Semaine 7==

==Semaine 8==

==Semaine 9==

==Semaine 10==

=Documents Rendus=

IMA4 2017/2018 P14

2018-02-07T17:02:51Z

Vdupont1 : /* Mercredi 07/02/18 */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

* 16 [pack 25] Capteur de contact (1 par côté) [https://fr.rs-online.com/web/p/capteurs-proximites/7985273/] '''Envisagés pour la seconde partie du projet mais non validés pour le moment !'''

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "sudo apt-get install exiftool" sur chaque Raspberry

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

<pre>#!/bin/sh

# CONFIGURATION

DIR="/home/pifou/Downloads"
EVENTS="create"

NB_X=1
NB_Y=1

# MAIN

inotifywait -m -e $EVENTS $DIR |
while read file
do

X1=0
Y1=0

X2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1 | awk '{print $1"/$NB_X"}' | bc
Y2=exiftool /home/pifou/Downloads/hide-and-seek.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f2 | awk '{print $1"/$NB_Y"}' | bc

echo "File recieved : $file";
omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 $DIR/$file;
PID=$!;
wait $PID;
rm -f $DIR/$file;
echo "File removed $file";
done

</pre>

==Semaine 5==

==Semaine 6==

==Semaine 7==

==Semaine 8==

==Semaine 9==

==Semaine 10==

=Documents Rendus=

IMA4 2017/2018 P14

2018-02-07T16:54:37Z

Vdupont1 : /* Mercredi 07/02/18 */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

* 16 [pack 25] Capteur de contact (1 par côté) [https://fr.rs-online.com/web/p/capteurs-proximites/7985273/] '''Envisagés pour la seconde partie du projet mais non validés pour le moment !'''

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "sudo apt-get install exiftool" sur chaque Raspberry

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

<pre>#!/bin/sh

# CONFIGURATION

DIR="/home/pifou/Downloads"
EVENTS="create"

# MAIN

inotifywait -m -e $EVENTS $DIR |
while read file
do

X1=0
Y1=0

X2=exiftool $DIR/$file | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1
Y2=exiftool $DIR/$file | grep "Image Size" | cut -d' ' -f25 | cut -dx -f2

echo "File recieved : $file";
omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 $DIR/$file;
PID=$!;
wait $PID;
rm -f $DIR/$file;
echo "File removed $file";
done

</pre>

==Semaine 5==

==Semaine 6==

==Semaine 7==

==Semaine 8==

==Semaine 9==

==Semaine 10==

=Documents Rendus=

IMA4 2017/2018 P14

2018-02-07T16:49:38Z

Vdupont1 : /* Mercredi 07/02/18 */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

* 16 [pack 25] Capteur de contact (1 par côté) [https://fr.rs-online.com/web/p/capteurs-proximites/7985273/] '''Envisagés pour la seconde partie du projet mais non validés pour le moment !'''

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "sudo apt-get install exiftool" sur chaque Raspberry

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

<pre>#!/bin/sh

# CONFIGURATION

DIR="path"
EVENTS="create"

X1=0
Y1=0

X2=exiftool /home/pifou/Downloads/dragons.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1
Y2=exiftool /home/pifou/Downloads/dragons.mp4 | grep "Image Size" | cut -d' ' -f25 | cut -dx -f2

# MAIN

inotifywait -m -e $EVENTS $DIR |
while read file
do
echo "File recieved : $file";
omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 $file
rm -f $DIR/$file;
echo "File removed $file";
done

</pre>

==Semaine 5==

==Semaine 6==

==Semaine 7==

==Semaine 8==

==Semaine 9==

==Semaine 10==

=Documents Rendus=

IMA4 2017/2018 P14

2018-02-07T16:05:13Z

Vdupont1 : /* Mercredi 07/02/18 */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

* 16 [pack 25] Capteur de contact (1 par côté) [https://fr.rs-online.com/web/p/capteurs-proximites/7985273/] '''Envisagés pour la seconde partie du projet mais non validés pour le moment !'''

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "sudo apt-get install exiftool" sur chaque Raspberry

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

<pre>#!/bin/sh

# CONFIGURATION

DIR="path"
EVENTS="create"

# MAIN

inotifywait -m -e $EVENTS --timefmt '%Y-%m-%d %H:%M:%S' --format '%$
while read date time file
do
echo "$date $time Fichier recu: $file";
rm -rf $DIR/$file;
ls $DIR;
echo "Has $file been removed ?";
done
</pre>

==Semaine 5==

==Semaine 6==

==Semaine 7==

==Semaine 8==

==Semaine 9==

==Semaine 10==

=Documents Rendus=

IMA4 2017/2018 P14

2018-02-07T16:04:50Z

Vdupont1 : /* Mercredi 07/02/18 */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

* 16 [pack 25] Capteur de contact (1 par côté) [https://fr.rs-online.com/web/p/capteurs-proximites/7985273/] '''Envisagés pour la seconde partie du projet mais non validés pour le moment !'''

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "sudo apt-get install exiftool" sur chaque Raspberry

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

{{boîte déroulante
| titre = Code du script
| contenu =
<pre>#!/bin/sh

# CONFIGURATION

DIR="path"
EVENTS="create"

# MAIN

inotifywait -m -e $EVENTS --timefmt '%Y-%m-%d %H:%M:%S' --format '%$
while read date time file
do
echo "$date $time Fichier recu: $file";
rm -rf $DIR/$file;
ls $DIR;
echo "Has $file been removed ?";
done
</pre>
}}

==Semaine 5==

==Semaine 6==

==Semaine 7==

==Semaine 8==

==Semaine 9==

==Semaine 10==

=Documents Rendus=

Modèle:Boîte déroulante/fin

2018-02-07T16:04:17Z

Vdupont1 :

<pre>
#!/bin/sh

# CONFIGURATION

DIR="path"
EVENTS="create"

# MAIN

inotifywait -m -e $EVENTS --timefmt '%Y-%m-%d %H:%M:%S' --format '%$
while read date time file
do
echo "$date $time Fichier recu: $file";
rm -rf $DIR/$file;
ls $DIR;
echo "Has $file been removed ?";
done
</pre>

Modèle:Boîte déroulante/fin

2018-02-07T16:03:39Z

Vdupont1 : Page créée avec « #!/bin/sh # CONFIGURATION DIR="path" EVENTS="create" # MAIN inotifywait -m -e $EVENTS --timefmt '%Y-%m-%d %H:%M:%S' --format '%$ while read date time file do e... »

#!/bin/sh

# CONFIGURATION

DIR="path"
EVENTS="create"

# MAIN

inotifywait -m -e $EVENTS --timefmt '%Y-%m-%d %H:%M:%S' --format '%$
while read date time file
do
echo "$date $time Fichier recu: $file";
rm -rf $DIR/$file;
ls $DIR;
echo "Has $file been removed ?";
done

IMA4 2017/2018 P14

2018-02-07T16:03:32Z

Vdupont1 : /* Mercredi 07/02/18 */

__TOC__
 

=Présentation générale=

==Description==

* '''Intitulé du projet''' : Proposer une solution permettant d'assembler des écrans de PC afin de créer un écran géant

Le renouvellement de matériel informatique continu entraîne un nombre grandissant d'écrans d'ordinateur qui sont difficilement réutilisables compte tenu de leur petite taille. (17")

Afin de leur donner une seconde vie, ce projet a pour but de construire une plateforme permettant d'assembler ces écrans en un écran géant d'une forme "quelconque"

<center>'''Exemple d'un cas d'écran carré'''
[[Fichier:Combinaison_ecrans.jpg]]
</center>

==Objectifs==

Afin de réaliser ce projet, il faudra :

* Ajouter un Raspberry Pi sur chaque écran afin de le rentre "intelligent".

* Créer une application permettant de prendre un flux vidéo et de le diriger vers l'écran visé.

* Permettre de déplacer facilement les écrans tout en maintenant le flux, que ce soit sur des configurations pleines en 2D ou des configurations plus complexes avec des espaces vides ou en 3D.

=Analyse du projet=

==Positionnement par rapport à l'existant==

==Analyse du premier concurrent==

==Analyse du second concurrent==

==Scénario d'usage du produit ou du concept envisagé==

==Réponse à la question difficile==

* Le positionnement des écrans et la communication entre ces derniers.

Pour une application telle qu'un écran géant composé de plusieurs écran, il est difficilement envisageable d'utiliser un système de coordonnées GPS pour repérer des écrans qui sont particulièrement proches les uns des autres.
En revanche il est tout à fait réaliste de penser à un système de capteurs de contact/proximité, disposés sur les bords des écrans pour leur permettre de s’emboîter puis il ne resterait qu'à exploiter les possibilités proposées par les Raspberry Pi ainsi qu'un système de coordonnées réalisé dans ce but pour déterminer où l'écran se situe par rapport aux autres.

* La gestion du flux vidéo

Le système sera potentiellement réalisé de sorte que chaque écran soit autonome dans son fonctionnement, une fois sa position relative déterminée au préalable.
En effet, pour le moment le problème était surtout dans le positionnement des écrans plus que dans la gestion du flux vidéo, à priori.

* "Est-ce que le système peut continuer de fonctionner si on retire l'un des écrans ?"

Pour pallier au problème d'un retrait d'écran, ou d'un disfonctionnement éventuel localisé, une solution possible est de fournir à chaque écran la totalité du flux vidéo.
Ceci permet dans un premier temps de s'affranchir d'un traitement vidéo avant distribution mais surtout que les autres écrans puissent fonctionner sans interruption due à un écran en particulier

* "Peut-il y avoir des décalages d'affichage entre les écrans ?"

Malgré l'absence de possibilités de test pour le moment, on peut néanmoins supposer qu'il n'y ait pas de décalage.
Chaque écran va recevoir le flux vidéo puis en fonction du positionnement des écrans, et on pourra utiliser le système de coordonnées pour effectuer une "selection" sur la partie à afficher.

Dans le cas d'une configuration de 4 écrans en rectangle, il faudrait donc que l'écran inférieur gauche n'affiche que l'image correspondante jusqu'à la moitié, ensuite l'écran inférieur droit s'occuperait de l'affichage de la partie inférieure droite, etc

En agrandissant le procédé à plus d'écrans, on trouve facilement une méthode de calcul.

<center>Exemple

</center>

=Préparation du projet=

==Cahier des charges==

Dans le cadre de ce projet où il s'agira d'être capable de fournir une solution matérielle à la problématique, on s'orientera vers un prototype n'incluant que 4 écrans. Ceci permet à la fois d'éviter un encombrement matériel mais aussi .

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

* 5 Raspberry Pi 3 [https://fr.rs-online.com/web/p/processor-microcontroller-development-kits/8968660/?src=raspberrypi] lien 2 [https://www.mouser.fr/ProductDetail/Adafruit/3055?qs=sGAEpiMZZMuG6%2fXKM6MUaQgA7zSPt2LlznodoAe%252bkgk%3d]

* Un Commutateur (5 Ports +)

* 5 Câbles Ethernet

* 4 Câbles VGA

* 4 Adaptateur VGA-femelle vers HDMI-mâle

* 16 [pack 25] Capteur de contact (1 par côté) [https://fr.rs-online.com/web/p/capteurs-proximites/7985273/] '''Envisagés pour la seconde partie du projet mais non validés pour le moment !'''

==Liste des tâches à effectuer==

* 1) Régler le problème de la gestion du flux vidéo par le réseau ainsi qu'au niveau des Raspberry-Pi

'''Hypothèse''': pour une configuration d'écran donnée, on suppose les écrans déjà intelligent et on dispose de leur emplacement relatif.

* 2) Une fois la première version fonctionnelle, s'orienter vers la mise en place du système intelligent

==Calendrier prévisionnel==

=Réalisation du Projet=
==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
|-
| Analyse du projet
| 0
| Lundi 15/01/18 : 3h30
Mercredi 17/01/18 : 4h
| Mercredi 24/01/18 : 4h
| Mercredi 31/01/18 : 4h
| Lundi 05/02/18 : 2h
|
|
|
|
|
|
|
|}

==Prologue==
==Semaine 1==

===Lundi 15/01/18===

* Première séance ayant pour but de synthétiser l'idée théorique souhaitée par le projet.

On imagine un système d'ensemble d'écrans autonomes mais qui communiquent leur emplacement entre eux, dans le sens où il n'est pas nécessaire de reconfigurer à chaque modification sur l'emplacement des écrans.

Le système est pour ainsi dire évolutif puisqu'à chaque modification, exemple: passage d'un écran géant de 2*2 à 2*3 ou 3*2 (ou plus), les affichages peuvent modifier la zone du flux vidéo à afficher afin de conserver une image sur la totalité des écrans.

De ce fait on peut imaginer des structures plus complexes, cylindriques dans le cas d'un flux d'une caméra à 360° ou plus simplement pour des simulateurs où les écrans seraient inclinés sans pour autant décrire un cercle autour de l'utilisateur.

Cependant, pour des raisons évidentes d'effectif, de temps il est nécessaire de se réduire à une solution moins ambitieuse mais néanmoins acceptable.

===Mercredi 17/01/18===

* Mise en place d'un cahier des charge réalisable dans le temps imparti par rapport à la réponse théorique que l'on souhaiterai apporter au problème.

Suite aux raisons évoquées précédemment, nous allons donc nous orienter vers un système à échelle réduite que nous ferons évoluer progressivement.

Comme prévu nous diffuserons le flux vidéo initial, ''envoyé par Ethernet par une Raspberry Pi à partir d'un fichier stocké sur une clé usb par exemple'', aux 4 Raspberry intégrées aux écrans via un switch donc également par Ethernet (le port HDMI des R-Pi étant uniquement une sortie)

<center>
'''Schéma'''
</center>

Nous effectuerons ensuite grâce aux R-Pi la modification du flux en fonction des écrans servant à l'affichage avant de rediriger la partie du flux qui nous intéresse vers les écrans.

*'''Remarque:''' Dans un premier temps, pour une configuration donnée et avec les emplacement des écrans connues, il s'agit uniquement de réaliser la conversion d'affichage.

Le fait de rendre les écrans intelligents n'est cependant pas ignoré et viendra dans un second temps, le choix de la méthode à employer étant encore en suspend. Nous allons cependant effectuer des hypothèses avec des capteurs.

* Soit X et Y les dimensions du flux vidéo
* Soit U,R,D,L les états des capteurs sur un écran donné (respectivement, Up, Right, Down, Left) (1 pour actifs, 0 pour inactif)
* Soit I,J les indices des écrans (I = 0/1 et J = 0/1)
* Soit nb_X et nb_Y respectivement le nombre d'écrans en fonction des coordonnées i.e les dimensions de notre écran géant

La configuration d'écran est la suivante:

<center>
'''Schéma (I,J)'''

0,1 ; 1,1

0,0 ; 1,0
</center>

Quel que soit l'écran, le flux qu'il devra recevoir sera situé entre [X1,X2] et [Y1,Y2].
Évidemment ces valeurs de l'emplacement de l'écran

* Y2 = Y * ( D||U ) * (I+1) / nb_Y
* Y1 = Y * D * I / nb_Y
* X1 = X * L * J / nb_X
* X2 = X * ( L||R ) * (J+1) / nb_X

==Semaine 2==

===Mercredi 24/01/18===
Début de la gestion réseau du flux vidéo.

Pour la partie théorique, nous allons donc procéder de la manière suivante :

Une Raspberry s'occupera de diffuser le flux sur le réseau via un commutateur. À partir d'un fichier vidéo interne.

Les autres R-Pi disposeront d'un fichier de configuration qui contient les coordonnées à afficher en fonction de la position de l'écran, dans la première partie ce fichier sera directement implanté avec un contenu propre à chaque R-Pi mais dans la seconde il s'agira de les modifier automatiquement.

Configuration eth0 sur la Raspberry pi :
iface eth0 inet static
address 192.168.1.<2+numero_rpi>
netmask 255.255.255.0

On commencera par créer un fichier fifo pour faire la transmission entre nc et OMXplayer

Lecture du réseau : nc -l -p <port> > /dev/shm/video.fifo

Affichage : omxplayer --crop x1,y1,x2,y2 /dev/shm/video.fifo

[https://elinux.org/Omxplayer] : Documentation OMX player

==Semaine 3==

===Mercredi 31/01/18===

Tentatives de communication PC (Source flux) à Raspberry (Écran) via nc : Échec

* [PC source] : | nc

* [Raspberry Écran - Terminal 1] : nc -l -p 12345 > /dev/shm/video.fifo

* [Raspberry Écran - Terminal 2] : omxplayer --crop x1,y1,x1,y2 /dev/shm/video.fifo

Avec x1,y1,x2,y2 les coordonnées des coins de la fenêtre à afficher

Problème rencontré : la Raspberry n'arrive pas à obtenir une adresse joignable malgré une connexion directe avec le PC en ethernet

* sudo nano /etc/network/interfaces

-> iface eth0 inet dhcp

* ifdown eth0

* ifup eth0

* ifconfig

-> inet adr:169.254.68.185

Seconde tentative avec VLC en mode Streaming sur le PC source et VLC en écoute de stream avec VLC également : Échec (IP de la source = ?)

Ligne de commande pour VLC de lecture

* vlc -vvv http://IP_SOURCE:8080/PATH --crop X_RESxY_RES+LEFT_CROP+TOP_CROP -f

PATH: paramètre donné lors du lancement du stream sur la machine source

X_RES : Résolution X de l'affichage (en pixel)

Y_RES : Résolution Y de l'affichage (en pixel)

LEFT_CROP : Largeur de la zone coupée en partant de la gauche (en pixel)

TOP_CROP : Hauteur de la zone coupée en partant du haut (en pixel)

-f : Full screen

* Test avec le mode de stream (une fois le problème résolu) : le lancement de la lecture sous VLC du côté de la raspberry entraîne des pertes considérables au niveau du flux vidéo avec des coupures très fréquentes (écran noir) ainsi qu'une forte consommation des ressources

<center><photo 95%></center>

==Semaine 4==

===Lundi 05/02/18===

Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.

<center><photo 0-3%></center>

===Mercredi 07/02/18===

Envoie avec succès d'un fichier vidéo via netcat du PC source vers la Raspberry

* $ nc -w 3 172.26.145.172 1234 < Downloads/dragons.mp4

Où 172.26.145.172 est l'adresse obtenue par ifconfig sur la Raspberry.

Réception avec :

* $ nc -l -p 1234 > Downloads/test.mp4

Commande de lecture :

* $ omxplayer --aspect-mode stretch --crop X1,Y1,X2,Y2 Downloads/test.mp4

Récupération de la résolution du flux vidéo (ou fichier dans le cas actuel) : exiftool

Nécessite un "sudo apt-get install exiftool" sur chaque Raspberry

* $ exiftool <file> | grep "Image Size" | cut -d' ' -f25 | cut -dx -f1

Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier

{{boîte déroulante
| titre = Code du script
| contenu = <pre>#!/bin/sh

# CONFIGURATION

DIR="path"
EVENTS="create"

# MAIN

inotifywait -m -e $EVENTS --timefmt '%Y-%m-%d %H:%M:%S' --format '%$
while read date time file
do
echo "$date $time Fichier recu: $file";
rm -rf $DIR/$file;
ls $DIR;
echo "Has $file been removed ?";
done
</pre>
}}

==Semaine 5==

==Semaine 6==

==Semaine 7==

==Semaine 8==

==Semaine 9==

==Semaine 10==

=Documents Rendus=

IMA4 2017/2018 P14

2018-02-07T15:56:08Z

Vdupont1 : /* Semaine 4 */

Discussion:Projets IMA4 SC & SA 2017/2018

2018-02-07T14:10:51Z

Vdupont1 : /* Fiche de présence */

== Notes sur les projets ==

{| class="wikitable"
| Projet || Analyse du projet || Retour sur l'analyse || Matériel || Mi-parcours || Wiki terminé || Rapport || Vidéo
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
| Présentation sans supports, bonne analyse de la concurrence. Par contre le scénario d'usage est à revoir en précisant l'usage pour le particulier.
| Le scénario est précisé mais aucune réponse aux questions difficiles "gestion des températures et procédure d'entretien".
| Rien.
|
|
|
|
|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
| Présentation focalisée sur les réseaux de neurones. Exercice mal compris (pas d'introduction du contexte, pas de scénario d'usage).
| Toujours pas d'analyse de la concurrence, ni de scénario d'usage. Pas de réponse aux questions difficiles "quel est le matériel ? quel est le protocole ? quelles sont les entrées du réseau de neurones ?".
| Une liste mais il manque des références vers les fournisseurs agréés (voir page de l'an dernier).
|
|
|
|
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Exercice correctement réalisé.
| Pas de réponse aux questions difficiles "Architecture de la source d'énergie (nombre de chemins d'énergie ?)".
| Rien.
|
|
|
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Présentation focalisée sur la création du site Web. Effort fait pour rédiger un scénario d'usage.
| Réponses aux questions mais l'analyse de la consommation est imprécise. 
| Du matériel listé dans la page Wiki mais à reporter en bas de la page des projets de cette année avec des références valides.
|
|
|
|
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Exercice correctement réalisé. Scénario d'usage à préciser sur la partie réseau de capteurs.
| Scénario d'usage non précisé. Pas de réponse à la question difficile.
| Du matériel listé mais sans référence, êtes-vous sur que le matériel n'a pas besoin d'être acheté ?
|
|
|
|
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Pas de support. Exercice très bien réalisé.
| Pas de réponse aux questions difficiles "quelle alimentation ? comment faire pour différencier les briques ? comment les briques vont-elles communiquer ? quelle sécurité vis-à-vis des enfants ?"
| Pas de liste de matériel.
|
|
|
|
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Rien à signaler (juste une confusion entre le MSP430 et le CC430).
| Questions difficiles évacuées. 
| Du matériel listé mais sans référence.
|
|
|
|
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Un peu rapide, exercice réalisé. 
| Pas d'analyse de la concurrence. Peu d'effort de rédaction. Des coquilles. Une réponse rapide à la question difficile.
| Du matériel listé mais pas forcément exhaustif et sans référence valide.
|
|
|
|
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Doublant
| Doublant
| Page Wiki vide, pas de liste de matériel.
|
|
|
|
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Présentation acceptable mais avec des supports non soignés. Pas d'analyse de la concurrence, pas de scénario d'usage.
| L'analyse de la concurrence et le scénario d'usage ont été ajoutés. Par contre pas de réponse aux questions difficiles "quelle sera l'autonomie de la balle et quel sera le système de rechargement ?".
| Pas de liste de matériel.
|
|
|
|
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Présentation acceptable mais avec des supports non soignés. Trouver des concurrents indirects. Une histoire mais pas de scénario d'usage.
| Page Wiki modifiée après la présentation. Une réponse incomplète à la question difficile. Trop de coquilles pour ce niveau d'études.
| Pas de liste de matériel.
|
|
|
|
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Doublant
| Doublant
| Aucune modification de la page Wiki depuis début octobre.
|
|
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Supports très textuels, pas de scénario d'usage mais une rédaction sur l'intérêt psychologique, pas vraiment de partie "concurrents".
| Un effort pour trouver des "concurrents", pas de réponses aux questions difficiles "combien de LEDs ? quelle alimentation pour quelle autonomie".
| Pas de liste de matériel.
|
|
|
|
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Bonne présentation orale. Utilisation du bluetooth peu convainquant. Pas de scénario d'usage. Un "concurrent" trouvé.
| Concept de scénario d'usage non compris. Une réponse à la question difficile très rapide et non convaincante.
| Une liste de matériel dans la page Wiki mais à insérer dans le tableau en bas de la page principale. Pas de référence (voir sur la page de l'an passé).
|
|
|
|
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Support assez corrects, sujet non entièrement compris, scénario d'usage minimal.
| Un problème dans le scénario d'usage : les conteneurs doivent être lancés sur un serveur. Une réponse acceptable à la question difficile.
| Pas de matériel particulier.
|
|
|
|
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Analyse très correcte.
| Réponse à la question difficile.
| Aucune liste de matériel.
|
|
|
|
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Présentation trop impécise, pas vraiment de scénario d'usage. Par contre des concurrents ont été présentés.
| Un scénario d'usage éloigné de la future utilisation. Trop de coquilles dans ce scénario. Réponse à la question difficile.
| Une liste du matériel mais pas dans la page principale. Pas de référence (voir page de l'an passé).
|
|
|
|
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Analyse très correcte. Un concurrent assez peu en rapport avec les essaims de robots mais dans la ligne des dispositifs de déminage.
| Pas de question difficile.
| Liste du matériel. Préciser pour le chassis.
|
|
|
|
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Objectif mal expliqué. Exercice réalisé.
| Mieux définir l'objectif suite à la visite en entreprise. Pas de réponse à la question difficile.
| Aucune liste de matériel.
|
|
|
|
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Excellente présentation et excellent travail préparatoire, Scénario d'usage à préciser, trouver des concurrents.
| Réponse à la question difficile.
| Aucune liste de matériel.
|
|
|
|
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Exercice réussi. Cependant précisez les acteurs dans le scénario d'usage.
| Pas de modification du scénario. Pas de réponse à la question difficile.
| Rien à redire sur la liste de matériel.
|
|
|
|
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Analyse très correcte.
| Réponses aux questions difficiles.
| Aucune liste de matériel.
|
|
|
|
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Sujet se prêtant peu à l'exercice mais très bonne présentation. Sujet travaillé.
| Pas vraiment de question, la suggestion est noté dans la page Wiki.
| Pas de matériel à commander.
|
|
|
|
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Analyse très correcte.
| Pas de réponse aux questions difficiles "Comment démarrer l'imprimante à distance ? Comment sera calibrée la plaque d’impression ?
Comment la plaque va se fixer sur le sol ? 
| Aucune liste de matériel.
|
|
|
|
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Le projet ne semble pas encore avoir été sérieusement étudié.
| Net effort de documentation de la page Wiki. Pas de réponse directe à la question difficile sur la Kinect mais une discussion sur le problème posé.
| Aucune liste de matériel.
|
|
|
|
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Contexte mal présenté, sujet flou. Scénario d'usage à préciser. Pas de contact avec les encadrants avant la présentation.
| Page de Wiki vide.
| Aucune liste de matériel.
|
|
|
|
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
| Doublant
| Page de Wiki assez vide.
| Aucune liste de matériel.
|
|
|
|
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Présentation très correcte.
| Pas de réponse à la question difficile. Page Wiki un peu vide.
| Pas de matériel à commander.
|
|
|
|
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
| Doublant
| Wiki avec quelques informations sur le travail accompli depuis fin novembre : étude sur modbus et labview. Quelques coquilles.
| Aucune liste de matériel.
|
|
|
|
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Présentation sans support. Trouver des concurrents indirects. Pas de scénario d'usage.
| Page Wiki vide.
| Aucune liste de matériel.
|
|
|
|
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Analyse très correcte.
| Page Wiki bien tenue. Ajoutez des illustrations.
| Quelques éléments sur le matériel dans la page Wiki mais aucune liste avec références.
|
|
|
|
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Exercice bien réalisé.
| Page Wiki très complète. Ajoutez des illustrations.
| Une liste probablement pas exhaustive.
|
|
|
|
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
| Doublant
| Page Wiki vide.
| Pas de matériel à commander.
|
|
|
|
|-
| PP1 [[IMA4 2017/2018 Pré-projet 1|Robot hexapode pour escalier]]
| Erasmus
|
|
|
|
|-
|}

== Fiche de présence ==

{| class="wikitable"
! Projet !! Elèves !! Séance 1 (17/01) !! Séance 2 (24/01) !! Séance 3 (31/01) !! Séance 4 (7/02) !! Séance 5 (14/02) !! Séance 6 (21/02) !! Séance 7 (7/03) !! Séance 8 (14/03) !! Séance 9 (21/03) !! Séance 10 (28/03) !! Séance 11 (4/04) !! Séance 12 (11/04) !! Séance 13 (18/04)
|-
| P1 [[IMA4 2017/2018 P1|Automatisation de la production de bière]]
|Quentin Boëns / Henri Carlier
|E304
|E304/305
|E304

|-
| P3 [[IMA4 2017/2018 P3|Sécurisation de l'Internet des Objets par surveillance globale]]
|Ji Yang
|E306
|E303
| Pas de salle 
|-
| P4 [[IMA4 2017/2018 P4|Développement d'un module d'énergie pour Internet des Objets]]
| Alexis Viscogliosi / Abass Ayoub
|C008
|C008
|E304 Alexis Viscogliosi Absent excusé pour entretien stage
|C008
|-
| P5 [[IMA4 2017/2018 P5|Réseau de capteurs de pollution]]
| Paul Ribeiro / Mehanna Naïf
|E303
|E301
|A204 Absents 
|E301
|-
| P6 [[IMA4 2017/2018 P6|Réseau LoRaWAN]]
| Antoine Gosse
| E306
| E306
| E306
|-
| P7 [[IMA4 2017/2018 P7|Brique pour apprentissage informatique]]
| Maëva Delaporte / Simon Blas
| E304 
| E304 
| E304 
|-
| P10 [[IMA4 2017/2018 P10|Portage de RIOT-OS sur MSP430 pour IOT]]
| Baptiste Cartier
| E306
| E301
| E306
|-
| P12 [[IMA4 2017/2018 P12|Système d'ostéophonie pour magicien]]
| Amine El Messaoudi / Simon Feutrier
| E301
| C201
| Pas de salle 
|-
| P14 [[IMA4 2017/2018 P14|Ecran géant modulaire]]
| Jade Dupont
|E304
|E304
|E304
|E304
|-
| P15 [[IMA4 2017/2018 P15|Balle vibrante connectée pour enfants sourd]]
| Thomas Cunin / Thibault Cattelain
| E304
| B306/E304
| Pas de salle (E304 - A305)
| E301
|-
| P16 [[IMA4 2017/2018 P16|Sous-chaussure chauffante pour docker]]
| Rémi Mairesse / Gustave Roux
| E304
| E301
| Pas de salle 
|-
| P17 [[IMA4 2017/2018 P17|Safe Watch]]
| Oumaima Naanaa
|E302
|E304
|E304
|E304
|-
| P18 [[IMA4 2017/2018 P18|Mandala électronique]]
| Lirui Zhang / Lihe Zhang
| E304
| E304
| E304
 Pas de salle 
|-
| P19 [[IMA4 2017/2018 P19|Bijou électronique]]
| Lijie Yao / Keren Qiang
| E303
| E304
| E304
|-
| P20 [[IMA4 2017/2018 P20|Solution de messagerie à base de conteneurs]]
| Maxime Creteur / Gao Fan
|E303
|E301
|A204 Absents 
|-
| P22 [[IMA4 2017/2018 P22|Horloge numérique DCF77, serveur de temps et ludique]]
| Amaury Knockaert / Fabrice Taingland
| E304
| E304
| E304/E302
|-
| P23 [[IMA4 2017/2018 P23|Table de bar connectée]]
| Matthieu Delobelle
| E306
| E306
| E303 - C201
|-
| P25 [[IMA4 2017/2018 P25|Essaim de robots]]
| Benjamin Canu / Ganix Etcheguibel
| E306
| E306
| E306
|-
| P30 [[IMA4 2017/2018 P30|Contrôle d'une caméra WiFi.]]
| Taky Djeraba / Thomas Hubert
| E306
| E306
| Pas de salle 
|-
| P32 [[IMA4 2017/2018 P32|Tribute to Peter Vogel]]
| Jean-Baptiste Watine / Antoine Untereiner
| E306/C201
| E301
| Pas de salle (C201) 
|-
| P35 [[IMA4 2017/2018 P35|Manette de jeu vidéo pour personne en situation de handicap]]
| Transley Gracias / Camille Saad
| E306
| E306
| E305
| E306
|-
| P39 [[IMA4 2017/2018 P39|Musique des plantes]]
| Xavier Chenot / Rodolphe Toin
| E306
| E306
| E306
|-
| P40 [[IMA4 2017/2018 P40|Exploration du réseau d'anonymisation Tor]]
| Antoine Duquenoy / Anthony Durot
| E306
| E306
| E306
|-
| P42 [[IMA4 2017/2018 P42|Automatisation de l'assemblage de LEGO]]
| Eloi Zalczer / Justine Senellart
|E302/E306
|E302/E306
|E304/E302
|-
|-
| P44 [[IMA4 2017/2018 P44|Reconnaissance d’objets via Traitement d’image]]
| Damien Narbais / Zoé Briois
| E306
| E301
| Pas de salle (E301)
| E304 + 17h réunion C00X
|-
| P49 [[IMA4 2017/2018 P49|Suivi de la qualité de l’air]]
| Hugo Delbroucq / Nicolas Havard
| E301
| INRIA
| Pas de salle 
|-
| P50 [[IMA4 2017/2018 P50|Etage commande de Centaure]]
|-
| P60 [[IMA4 2017/2018 P60|Commande de niveaux d’eau]]
| Claire Vandamme / Alexandra Villa
|C008
|C008
|Hors Polytech/B106 Pas de salle Absentes 
|-
| P64 [[IMA4 2017/2018 P64|Simulation Labview et mise en réseau Modbus d’un ascenseur]]
|-
| P65 [[IMA4 2017/2018 P65|Exosquelette pour apprentissage]]
| Florian Le Foll
| E301
| E301
| Pas de salle 
|-
| P66 [[IMA4 2017/2018 P66|Coupe de France de robotique]]
| Carval Amaury
| fabricarium
| fabricarium puis Hors Polytech
| E304
|-
| P67 [[IMA4 2017/2018 P67|Scanner 3D DIY]]
| Erwan Dufresne
| E302/E306
| E301
| E304
|-
| P68 [[IMA4 2017/2018 P68|Générateur de chronogrammes d'ordonnancement]]
|}

IMA4 2017/2018 P14

2018-02-05T14:59:45Z

Vdupont1 : /* Réalisation du Projet */

IMA4 2017/2018 P14

2018-02-05T14:34:39Z

Vdupont1 : /* Feuille d'heures */

IMA4 2017/2018 P14

2018-01-31T17:40:12Z

Vdupont1 : /* Mercredi 31/01/18 */

IMA4 2017/2018 P14

2018-01-31T17:29:10Z

Vdupont1 : /* Mercredi 31/01/18 */

IMA4 2017/2018 P14

2018-01-31T17:28:42Z

Vdupont1 : /* Mercredi 31/01/18 */

IMA4 2017/2018 P14

2018-01-31T17:27:36Z

Vdupont1 : /* Mercredi 31/01/18 */

IMA4 2017/2018 P14

2018-01-31T16:25:40Z

Vdupont1 : /* Mercredi 24/01/18 */

IMA4 2017/2018 P14

2018-01-31T16:24:59Z

Vdupont1 : /* Mercredi 31/01/18 */

IMA4 2017/2018 P14

2018-01-31T15:49:10Z

Vdupont1 : /* Feuille d'heures */

IMA4 2017/2018 P14

2018-01-31T15:47:10Z

Vdupont1 : /* Mercredi 31/01/18 */

IMA4 2017/2018 P14

2018-01-31T13:59:43Z

Vdupont1 : /* Réalisation du Projet */

Discussion:Projets IMA4 SC & SA 2017/2018

2018-01-31T13:57:20Z

Vdupont1 : /* Fiche de présence */

Discussion:Projets IMA4 SC & SA 2017/2018

2018-01-24T18:24:59Z

Vdupont1 : /* Fiche de présence */

Discussion:Projets IMA4 SC & SA 2017/2018

2018-01-24T18:24:24Z

Vdupont1 : /* Fiche de présence */

IMA4 2017/2018 P14

2018-01-24T17:37:16Z

Vdupont1 : /* Réalisation du Projet */

IMA4 2017/2018 P14

2018-01-24T15:12:36Z

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

IMA4 2017/2018 P14

2018-01-24T14:41:06Z

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

IMA4 2017/2018 P14

2018-01-24T14:40:04Z

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

IMA4 2017/2018 P14

2018-01-17T17:45:07Z

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

IMA4 2017/2018 P14

2018-01-17T17:44:26Z

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

IMA4 2017/2018 P14

2018-01-17T17:43:14Z

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

IMA4 2017/2018 P14

2018-01-17T17:36:56Z

Vdupont1 : /* Préparation du projet */

IMA4 2017/2018 P14

2018-01-17T17:16:48Z

Vdupont1 : /* Mercredi 17/01/18 */