IMA4 2017/2018 P14 : Différence entre versions

De Wiki de Projets IMA
(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
  
{{boîte déroulante
 
| titre = Code du script
 
| contenu =
 
 
<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


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"

Exemple d'un cas d'écran carré

Combinaison ecrans.jpg

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.

Exemple

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 [1] lien 2 [2]
  • 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

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
<photo 95%>

Semaine 4

Lundi 05/02/18

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

<photo 0-3%>

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

Semaine 5

Semaine 6

Semaine 7

Semaine 8

Semaine 9

Semaine 10

Documents Rendus