IMA4 2017/2018 P14 : Différence entre versions
(→Mercredi 07/02/18) |
(→Mercredi 07/02/18) |
||
Ligne 292 : | Ligne 292 : | ||
Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier | Script d'observation et d’exécution d'action sur la création d'un fichier dans un dossier | ||
− | |||
− | |||
− | |||
<pre>#!/bin/sh | <pre>#!/bin/sh | ||
Ligne 313 : | Ligne 310 : | ||
done | done | ||
</pre> | </pre> | ||
− | |||
==Semaine 5== | ==Semaine 5== |
Version du 7 février 2018 à 16:05
Sommaire
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"
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.
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
- 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é) [3] 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
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)
Schéma
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:
Schéma (I,J)
0,1 ; 1,1
0,0 ; 1,0
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
[4] : 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
Semaine 4
Lundi 05/02/18
Omxplayer demeure plus adapté puisqu'il n'entraîne pas une sur-consommation.
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
#!/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