P14AB12 Surveillance de Zones dangereuses et protégées par Vision

Projet GE2-GE3 2013 : P14AB12 Surveillance de Zones dangereuses et protégées par Vision
Entreprise / Client : ERDF/Marc Hoerner
Auteurs : Nicolas MENDES, Yannick AMBLARD
Responsable Projet : Sebastien Lengagne
Tuteur industriel : Pascal Fickinger

1. Résumé
2. Abstract
3. Introduction
4. Présentation du Sujet

1. Présentation globale
2. Balisage
3. Synoptique

5. Cahier des Charges

6. Développement

1. Problématiques
2. Faisabilité
3. Etude Théorique
4. Solutions
5. Déroulement du projet

1. Sous-traitance
2. Stratégie retenue
3. Création de la zone dangereuse
4. Détection de la personne
5. Mise en commun des programmes
6. Implantation sur Raspberry Pi

7. Gestion de Projet

1. W.B.S.
2. Gantt

8. Notes d'application

1. sujet 1
2. sujet 2

9. Bilan

1. Etat d'avancement
2. Documents et fichiers
3. Perspectives

10. Bibliographie


Résumé

Le projet intitulé "Surveillance de zones dangereuses et protégées par vision" est proposé par M. Marc Hoerner travaillant à l'entreprise ERDF Lyon. M. Hoerner souhaite la réalisation d’un système qui complèterait le balisage présent sur les différents chantiers d’ERDF afin de protéger la vie du personnel qui y travaillerait. Le projet étant large, après découpage de ce dernier en plusieurs sous-problèmes et discussion avec le client à ce sujet, la priorité fut donnée à la réalisation d’un prototype réalisant la fonction voulue pour une seule caméra sur un balisage précis. Ce prototype pourra ensuite être généralisé à plusieurs caméras.


Abstract

The project titled “Monitoring of dangerous areas and protected by vision “is proposed by Marc Hoerner who is working at ERDF Lyon company. Sir Hoerner would like the creation of a system which is able to complete the markers on the construction site in order to protect construction site’s staff which could work on. The project, which is big, after cutting it into smaller problem and discussion with the client, the priority is to make a prototype which will make the wanted function for only one camera with precise markers. This prototype could be generalize to many cameras later.


Introduction

Dans le cadre du cursus Génie électrique à Polytech Clermont-Ferrand, chaque étudiant doit mener à bien un projet. Ces projets sont réalisés en binôme et ont pour vocation de mettre en pratique les acquis théoriques de la formation. Le projet présenté est proposé par ERDF Lyon. ERDF est une filiale à 100% d'EDF et gère 95% du réseau électrique français. L'entreprise ERDF a été créée en 2008 et reprend les activités d'EDF Gaz de France distribution et EDF réseau distribution. Le projet présenté ici a pour but de protéger le personnel des chantiers d’ERDF des éventuels dangers que peuvent représenter les installations en maintenance sur les chantiers d’ERDF.
Pour ce projet, notre interlocuteur sera M. Marc Hoerner. Notre responsable de projet génie électrique sera M. Sebastien Lengagne et notre tuteur industriel sera M. Pascal Fickinger.


Présentation du sujet

1.Présentation globale

De par l'importance d'ERDF, cette entreprise possède de nombreux sites. Certains d’entre eux ont parfois besoin de maintenances qui peuvent durer de deux mois à un an. Le personnel réalisant cette maintenance peut être exposé à des dangers dûs aux installations électriques à proximité des chantiers. ERDF souhaite par conséquent protéger ce personnel d’un danger de mort.
Le système à concevoir évoluera sur différents chantiers qui auront une surface moyenne de 5000 m². Les zones à protéger peuvent être multiples. Un balisage est déjà présent sur les chantiers, cependant ERDF souhaite renforcer un peu plus l’information de danger déjà présente, le système sera donc un complément du balisage.

2.Balisage

Ce balisage définit les zones dangereuses à ne pas franchir sur un chantier.
Le personnel a tendance à franchir ce balisage afin de gagner du temps sur le chantier. Ce franchissement peut avoir de graves conséquences sur le personnel car il peut entraîner des blessures voire la mort des personnes étant donné qu’il y a présence de matériel sous tension. Cependant, une zone dangereuse peut aussi être une zone sans équipements sous tension mais qui comporte tout de même un risque de blessure voire de mort.

Sur la photo est représenté le balisage d’un chantier pour une zone dangereuse sous tension :

Le chemin sécurisé est délimité par une chaîne rouge et blanche, cette chaîne informe qu'il y a un danger de l'autre côté. Cependant, le balisage ne sert pas seulement à informer d'un danger, il peut aussi signifier qu'une installation est mise hors tension ou informer de la nature d'une zone. Les différents balisages et leurs significations sont résumés sur la figure suivante:

Sur la photo ci-contre est représenté le balisage d’un chantier pour une zone dangereuse hors tension. Le balisage pour une zone dangereuse est le même peu importe la nature de son danger.

En revanche, la chaînette n’est pas le seul moyen d’indiquer qu’une zone est dangereuse, il y a parfois utilisation de barrières visibles sur la photo suivante. Ces barrières sont également de couleur rouge, et sont plus dissuasives que la chaînette rouge et blanche.

L'objectif de ce projet est donc d’avertir une personne qu’elle sort du balisage1 mais aussi d’avertir les autres membres du personnel présent sur le même chantier qu’une personne est potentiellement en danger.

3.Synoptique

Le synoptique créé à partir des éléments à disposition est visible sur la figure suivante. Sur la gauche apparait les entrées du système, en haut il y a les contraintes qu’imposent le milieu où évoluera le système, enfin sur la droite il y a les sorties du système.


Cahier des charges

2.1 Fonction principale
La principale fonction du système sera de détecter la sortie du balisage d'une personne. Il faudra alors que le système déclenche une alarme afin d'informer la personne qu'elle sort du balisage ainsi que les autres personnes sur le chantier. Notre client (M. Hoerner) a également demandé si possible un renvoi visuel sur les véhicules du chantier de l'image de la personne sortant du balisage. Cette image serait issue des caméras ayant détecté la sortie du balisage d'une personne. Le système devra par ailleurs différencier un animal et un humain.

Fonction principale 1 : Avertir de la sortie d'une personne du balisage

Fonction principale 1.1 : Détecter la sortie du balisage d'une personne
Fonction principale 1.2 : Déclencher une alarme
Fonction principale 1.3 : Afficher une image de la personne sortant du balisage sur les véhicules du chantier
Fonction principale 1.4 : Différencier un animal et un humain

2.2 Contraintes

Contrainte 1 : évoluer dans un environnement extérieur

Contrainte 2 : être portable
Contrainte 2.1 : être transportable
Contrainte 2.2 : Encombrement : tenir sur un feu de chantier (fixé par le client)

Contrainte 3 : Avoir une durée d'installation inférieure à 3 heures (imposé)

Contrainte 4: Avoir une maintenance simple
Contrainte 4.1 : L’accès à la batterie pour son remplacement ainsi que l’entretien du système ne doit pas durer plus d’une heure (compris dans les 3 heures d’installation)

Contrainte 5 : Avoir un temps de réponse inférieur à la seconde (fixé par le client)

Contrainte 7 : Avoir une autonomie d'au moins une journée (flexible)

Contrainte 8 : Prix à chiffrer


Développement

1.Problématiques

Ce projet possède de nombreuses problématiques, c'est pourquoi un découpage en sous-problèmes a été nécessaire, voici le découpage en question :

Implantation du système : Cela correspond à comment implanter les caméras sur les sites en travaux à partir d'un plan du chantier. Il s’agit ici d’optique et de géométrie.

Communication : Il s’agit de la communication entre les différents éléments du système ainsi que le renvoi visuel sur les véhicules du chantier. Plus particulièrement la communication sans fil, la portée ainsi que les problèmes de CEM (Compatibilité ElectroMagn?étique).

L'alimentation : Après des recherches, il est apparu que le système est susceptible de consommer beaucoup d’énergie. Par conséquent une étude spécifique sur les batteries est nécessaire. Cette étude permettra de définir la méthode de rechargement de la batterie ainsi que l’autonomie.

Interaction avec le personnel : Pour définir les zones dangereuses, il y aura un échange entre une personne physique et un ordinateur qui permettra de les définir (étant donné que les chantiers changent et que les zones à protéger peuvent ne pas toujours être les mêmes). Il y aurait la création de l’IHM (Interface Homme Machine) afin que cette dernière soit conviviale et simple d’utilisation.

Prototype : Création d’un système permettant la surveillance d’une seule zone spécifique. Cette zone comportera un balisage précis. Le système sera composé d’une caméra permettant l’acquisition de la vidéo ainsi que d’un PC (ou équivalent) pour réaliser le traitement de l’image et d’une alarme alertant d’un franchissement du balisage. Le système devra reconnaître le balisage automatiquement et surveiller le franchissement de celui-ci. Il pourra être ensuite généralisé à plusieurs caméras pour couvrir tous les chantiers.

2.Faisabilité

Chacun des éléments présentés dans la partie précédente nécessite une étude approfondie de faisabilité pour chaque point.

Étant donné le volume horaire de 140 heures consacrées aux projets à Polytech Clermont-Ferrand pour chaque membre du binôme, il était impossible de couvrir toutes les problématiques du projet. Après discussion avec le client M. Hoerner la priorité est donnée au prototype.

Ce prototype sera donc une application à une seule caméra couvrant une zone délimitée et précise (que nous préciserons afin que ce système soit généralisé). Le fonctionnement sera bien entendu de jour et en extérieur. Il respectera les contraintes précédemment définies (et remplira également la fonction principale énoncée dans le cahier des charges mais appliquée à une seule caméra).

Cependant, il y aura dans un premier temps développement d’un prototype ne reconnaissant pas automatiquement le balisage. Un opérateur devra cliquer sur les zones à risques, les clics permettront de définir des polygones de zones à risques qui après traitement (au moyen d’algorithmes) réaliseront la fonction voulue. La reconnaissance automatique du balisage peut présenter un fort taux d’erreur (en raison par exemple de personnes étant habillé de la même couleur que le balisage ou encore si le balisage n’est pas respecté sur le chantier), la première méthode (avec les clics) permet de garantir le fonctionnement désiré du prototype. Si le temps le permet il y aura ensuite développement du même prototype avec reconnaissance automatique du balisage.

De plus, le choix de la caméra sera notamment motivé par sa précision (voir étude théorique). Il faudra qu’un pixel de la caméra puisse contenir un maillon de la chaîne rouge et blanche (interdisant l’accès à une zone) afin de pouvoir reconnaitre ce dernier au niveau des algorithmes détectant automatiquement le balisage. Un maillon de chaîne mesure 3 cm.

De plus, le balisage sur le chantier devra respecter le code couleur de la figure 1. Dans le cas contraire le système fonctionnera uniquement avec l’opérateur définissant au préalable les zones dangereuses. En d’autres termes, la reconnaissance automatique du balisage sera faussée et le système ne fonctionnera pas correctement.

3.Etude Théorique

Du fait que le système possède une caméra, une étude spécifique d’optique est nécessaire afin de déterminer les caractéristiques de la caméra. Grâce à cette étude les distances nécessaires au bon fonctionnement de la caméra seront définies. Il y aura aussi explication sur comment obtenir l’angle couvrant une zone spécifique. De plus, il est possible de calculer la précision de la caméra, cette dernière sera donnée pour un pixel.
Le schéma présenté sur la figure suivante montre que plus la focale est grande et plus l’angle couvert est petit :

Pour cette étude, les calculs seront effectués grâce à des bases d’optique simplifiées qui correspondent au schéma visible sur la figure suivante:

Explication des variables :
- LF est la distance que l’on peut surveiller.
- L est la résolution de l’image que l’on récupère.
- f est la focale de la caméra.
- Angle couvert est l’angle que la caméra peut visualiser. Cet angle est calculé grâce à la focale de la caméra.
- DF est la distance où est la caméra par rapport à la zone à surveiller.
Le calcul suivant (trigonométrie) relie la distance pouvant être surveillée, la distance à laquelle on place la caméra et l'angle couvert :

tan((angle couvert)/2)=(LF/2)/DF

Connaissant l'angle couvert et la distance à laquelle on souhaite poser la caméra, on déduit du calcul précédent la distance LF (distance protégée).

Une règle de trois permet ensuite de trouver la distance modélisée par un pixel de l’image. La précision avec laquelle l’image est traitée est donc trouvée. Les résultats trouvés sont une moyenne de la vraie précision, cela permet d’avoir une idée de la précision avec laquelle le traitement d’images sera réalisé.

Par la suite, deux calculs différents sont présentés :

1er calcul:
Il permet de déterminer LF ainsi que la précision. Les valeurs de DF et la focale soit l'angle couvert sont connues, les focales choisies ici sont les plus répandues sur le marché.

Pour f=8mm soit 180°

Un angle de 180° ne pourra pas être représenté à cause de nos simplifications. Le calcul donnerait une distance LF égale à l’infini, ce qui est impossible. Par conséquent on approximera cet angle à 179°. Les précisions sont rassemblées dans le tableau suivant :

Pour f=20mm soit 94°, les précisions sont rassemblées dans le tableau suivant :

Voici un exemple de calcul de la précision pour une focale de 8mm soit 94° et une distance de DF de 10 m.

La distance LF vaut alors 21,45m (déduit du calcul précédent). En divisant LF par le nombre de pixels (1600), il vient que 1 pixel contient 0,01340461mètres pour LF = 21.45m et une valeur de L =1600pixel (la résolution choisie ici est de 1600x1200 pixels, donc la distance LF sera contenue dans les 1600 pixels, on en déduit la distance dans un pixel).

Pour f=28mm soit 75°, les précisions sont rassemblées dans le tableau suivant :

Toutes les précisions sont rassemblées dans les tableaux précédents en fonction de plusieurs distances LF

2ème calcul:
Il permet de déterminer l'angle nécessaire pour couvrir une distance LF à une distance DF.

Exemple de calcul pour un LF de 100m en faisant varier DF (2,5,7,10m)

Pour une distance LF de 100m et une distance DF de 10m l’angle sera de 157,38°.

Deux approches différentes ont été présentées : la première qui correspond à l'utilisation de caméra ayant des résolutions existantes sur le marché et permettant donc de connaître la précision disponible avec ces caméras et la seconde permet de, connaissant la précision que l'on souhaite, déduire l'angle que doit couvrir cette caméra et ensuite de retrouver la distance focale.

4.Solutions

Pour réaliser le prototype, les solutions seront les suivantes :

-La caméra sera choisie par le client. Le choix de cette caméra sera motivé par la précision voulue par le client, cette précision sera déduite du tableur et des calculs expliqués dans la partie théorique. Cependant, certains modèles de caméra seront enlevés de la proposition de choix. En vue d’une reconnaissance automatique du balisage, il est nécessaire que la précision de la caméra permette de distinguer le balisage. Les dimensions du balisage permettront de supprimer des caméras n’ayant pas les spécifications voulues.

-Le traitement d’image se fera grâce à des algorithmes écrits à l’aide la bibliothèque OpenCV2?. Une fois le fonctionnement de l’algorithme validé, une implantation sur un mini PC Raspberry Pi (mis à disposition) sera effectuée afin de proposer au client une première implantation.

5.Déroulement du projet
1. Sous-traitance

Nous avons proposés deux sujets de sous-traitance pour les GE4. Le premier étant une recherche de caméra basé sur différents critères et le deuxième étant la réalisation de scénarios filmés.

- Choix caméra

Ils nous ont fournit un comparatif de caméras sous forme de tableau Excel. Les informations fournies dans ce tableau sont le prix, les dimensions, les caractéristiques et les résolutions.

- Création de scénario

Afin de pouvoir tester notre algorithme, la sous-traitance devait réaliser une base de données de vidéos. La base de données de vidéos a été faite avec deux types de caméras: Un camescope et une Gopro. Les scénarios ont été filmé avec différentes hauteurs de tournage: Hauteur d'un trépieds d'appareil photo (1m50) et hauteur d'un étage (3m).

On peut voir l'effet fisheyes de la Gopro sur la photo de droite.

La sous-traitance a du réaliser différents scénarios. Voici un exemple de scénarios:
-Mettre en place le balisage
-Positionner la caméra en face du balisage
-Filmer une personne franchissant le balisage

Nous avons eu la chance de pouvoir réaliser certains scénarios sur un chantier ERDF à Beaumont. Ceci nous a permit d'être au plus proche de la réalité durant les test réalisés sur nos algorithmes.

2. Stratégie retenue

Pour réaliser le système souhaité, notre stratégie a été la suivante : on positionne une caméra en face du balisage, un opérateur vient alors définir la zone dangereuse et la détection se lance. La position de la caméra a été fixer arbitrairement mais en cohérence avec la configuration des chantiers que nous avions visités (cette stratégie semblait la plus appropriée). La hauteur sera variable tout au long des tests effectués afin de voir si une hauteur pose problème. La définition de la zone dangereuse par une personne correspond en réalité à la projection au sol du balisage. La photo ci-contre illustre la stratégie du système.

Le carré rouge représente la zone dangereuse et donc la projection au sol du balisage. On va ensuite s'intéresser à la position des pieds. Nous avons choisi de repérer le point le plus bas du corps humain (à savoir le pied) afin de diminuer le taux d'erreur du système. Il s'avère que si la caméra voit le pied de la personne dans la zone, alors cette dernière est dans la zone. Si nous avions choisi par exemple la cuisse, la caméra aurait pu voir le point choisi (sur la cuisse) dans le balisage alors qu'en réalité la personne serait seulement devant la caméra sans être dans la zone.

3.Création de la zone dangereuse

L'idée de cette partie est de créer la zone dangereuse, cette zone sera créer par un opérateur. Afin de créer celle-ci, on utilisera OpenCV qui contient des fonctions le permettant. Lors du lancement du programme, il y a la fenêtre suivante qui apparait:

Cette fenêtre permet à l'utilisateur de créer soit une zone rectangulaire (dans l'hypothèse ou la zone est parfaitement rectangulaire et dans le but d'être le plus précis possible lors de la définition de la zone) :

Soit de fournir plusieurs points, puis à partir de ces points de tracer le polygone (dont chaque point est un sommet). Cette option est disponible dans l'éventualité ou la zone ne serait pas rectangulaire et toujours dans l'optique d'avoir une zone la plus précise possible :

Maintenant que la zone est définie, il convient de détecter un point à l'intérieur de celle-ci. Afin de réaliser cela, nous avons décider d'utiliser un algorithme appeler collision. Considérons un polygone, on peut décomposer un polygone en ensembles de segments (voir figure ci dessous). On rappelle qu'un rectangle est polygone particulier.

Considérons à présent le segment AB correspondant au coté AB du polygone et le point P dont on veut connaitre la position.

On crée alors les vecteurs D et T comme sur la photo ci-dessous :

On s'intéresse ensuite au déterminant d de ces vecteurs, d= (Dx*Ty) - (Dy*Tx)
Si d>0 : Le point est à gauche du segment
Si d<0 : Le point est à droite du segment
Si d=0 : Le point est sur le segment
Enfin, si durant tout le parcours du polygone (donc si pour chaque segment) le point est toujours à droite ou toujours à gauche alors le point est à l'intérieur du polygone. A ce stade, nous étions apte à détecter la présence ou non d'un point dans une zone défini par un opérateur.

4.Détection de la personne


Le but de cette partie est de fournir les coordonnées du point le plus bas de la personne en mouvement afin que la tâche définition de la zone dangereuse déclenche l’alarme.
On va devoir détecter les personnes en mouvement. Afin de pouvoir réaliser cette fonction, on utilisera des fonctions d’OpenCV.
La stratégie retenue afin de détecter les personnes en mouvement est de détecter le fond de l’image et de faire une comparaison avec l’image actuelle à l’aide de fonctions Gaussienne intégrées aux fonctions OpenCV. Tout ce qui se sera déplacé entre les deux images fera partie d’une personne en mouvement.
La masse en mouvement sera donc représentée par un ensemble de pixel blanc.

Après une recherche bibliographique, nous sommes tombé sur une comparaison de 26 algorithmes de détection du fond et de la forme et nous avons choisis d’utiliser l’algorithme Mixture of Gaussian V2 (MOG2) du fait qu’il avait un temps d’exécution rapide qu’il était intégré à OpenCv, de plus il est possible de différenciée l’ombre de la masse en mouvement.

Source: https://github.com/andrewssobral/bgslibrary

Comment fonctionne l’algorithme de détection de la personne en mouvement ?

On utilise la mixture of Gaussian V2 afin de détecter la personne en question. On va supprimer le bruit que l’on peut avoir après avoir utilisé la fonction. Par la suite, on crée le contour de la personne. Finalement, on recherche les coordonnées du point le plus bas de ce contour qui servira à la détection ou non dans la zone dangereuse. Dans notre algorithme, nous rajoutons un point vert grâce à ses coordonnées qui sera utile afin de visualiser si la personne franchit le balisage (pour les test notamment).

5.Mise en commun des programmes

- Résultat :

Grâce à la base de données que la sous-traitance a effectuée pour nous, nous avons pu faire fonctionner notre algorithme sur ces vidéos et par conséquent évaluer notre algorithme.
Le pourcentage de réussite de notre algorithme est donné via ce tableau :

On peut voir qu’il n’y a pas une grande différence entre la Gopro et le caméscope. Nous avons un pourcentage moyen de réussite de 61,25 %

Les 40% défavorables s'expliquent par le temps ensoleillé qui via l'ombre fausse le résultat. Pourtant, nous avions choisi un algorithme de détection qui permettait de différencier l’ombre de la personne. On peut voir sur ces deux images que la personne qui va franchir la zone dangereuse ne sera surement pas détecter du fait que l’ombre est pris en compte comme une personne en mouvement, le point le plus bas est alors faux. L’orientation de l’ombre nous pose donc un problème.

Le rectangle bleu est le rectangle le plus proche du contour rouge. On voit bien que l’ombre n'est pas différencier.

Un autre cas défavorable est lorsqu’une personne qui franchit le balisage est cachée par une autre personne devant comme nous le montre cette image :

On peut donc voir que notre algorithme détecte comme si il n’y avait qu’une seule personne. Ce cas est un peu ambigu car on peut se dire que la deuxième personne qui cache la première personne qui est dans la zone dangereuse pourrait la prévenir qu’il n’a pas le droit d’être dans cette zone. C’est une question de bon sens.

Un autre cas défavorable est lorsqu’une personne passe devant la caméra et cache l’objectif. Il y a un changement rapide de fond qui fait dysfonctionner notre algorithme du fait qu’il a du mal à rafraichir le fond de l’image. Ce cas est souvent rencontré lorsque nous utilisons la caméra à une hauteur basse.

Solutions :

Nous avons essayé de trouver une solution pour supprimer ces problèmes.
On a trouvé un autre algorithme de détection de piétons appelé HOGdetector mais celui-ci utilise beaucoup de temps d’exécution par exemple pour une vidéo de 1 minutes le temps d’exécution s’élève à 15 minutes. Ce qui n’est pas envisageable sachant que notre système doit avoir un temps de réponse de moins d’une seconde du fait que l’utilisateur qui franchit cette zone dangereuse peut être en danger de mort.

Une autre solution a été de faire varier un paramètre de notre algorithme Mixture of Gaussian V2. Celui-ci permettait de faire varier le taux de seuillage de l’ombre. Lorsque l’on agit sur ce paramètre, on arrive à supprimer l’ombre. On peut voir sur ces deux images que lorsque l’on a diminué ce taux, l’ombre est supprimée et par conséquent le point le plus bas de la masse en mouvement est bien le pied de la personne :

Au vue de ces résultats nous avons réévalué notre algorithme en changeant manuellement le seuillage de l’ombre afin de détecter le pied de la personne sans problème d’ombres.
Nous n’avons pas réussi à automatiser ce changement de valeur du seuillage de l’ombre que l’on expliquera dans le point suivant.
Pour le moment, voici le pourcentage de réussite de notre programme :

Le pourcentage de réussite de notre programme est de 75,5% soit une augmentation de 14,25%. On arrive à augmenter le pourcentage de réussite mais nous n’arrivons pas à automatiser ce changement du paramètre de seuillage de l’ombre.

- Piste abandonnée

Parmi les pistes que nous avons abandonnées, il y a notamment la détection avec un système de gestion de couleur appelé HSV. Les images que nous voyens sont en RGB (Rouge, Bleu, Vert), il existe un autre système de gestion de couleurs appelé HSV (teinte, saturation valeur). Nous nous sommes intéressés à l'évolution de la valeur d'un pixel au cours du temps quand ce pixel appartient au fond, à la personne, à l'ombre et retourne au fond. Voici les courbes RGB (en haut) et HSV (en bas).

On peut voir qu'aucune de ces courbes ne se démarquent des autres, l'évolution de chaque courbes est similaire (un pic lorsque le pixel appartient à l'ombre). si nous aurions vu une courbe se comporter différemment (absence de pic) nous aurions pu nous baser sur la détection en HSV pour régler le problème de l'ombre or ici cela est impossible. La piste HSV a donc été abandonnée.

6.Implantation sur Raspberry PI

Afin de proposer un début d'implantation au client, nous avons choisi d'implanter notre programme sur un mini PC appeler Rapsberry Pi. Ce mini PC est visible sur l'illustration ci-dessous. Le raspberry que nous avons utilisé est de type A.

OpenCV fonctionne sur le raspberry. Le programme fonctionne également sur le raspberry à l'aide d'une webcam connecté sur un port USB. Malheureusement, le temps de réponse est bien supérieur à la limite fixée par le client dans le cahier des charges. Ce temps de réponse peut être réduit en supprimant l'affichage des différentes fenêtres du raspberry mais on est toujours bien supérieur à la contrainte temporelle du temps de réponse fixée par le client. Par conséquent la configuration du raspberry (700 MHZ, 250 mo de RAM) est insuffisante pour faire fonctionner notre programme. En revanche, si les performances du raspberry s'améliorent au cours du temps, le programme pourrait fonctionner sur ce mini PC.


Gestion de projet

---
W.B.S.

La décomposition du travail est visible sur figure suivante. Les parties « création cahier des charges », « dimensionnement » et « installation/prise en main » ont été réalisées pendant la phase d’avant-projet. Les autres parties seront traitées pendant le projet de 5ème année.

Les parties «choix de la caméra » est réalisé par la sous-traitance. Les études réalisées en avant-projet motiveront ce choix.

La phase de « détection manuelle » sera la priorité de notre projet, cette dernière est expliquée dans la partie faisabilité.


Gantt
Sur les 2 illustrations suivantes sont visibles le planning de l’avant-projet (entre Février 2014 et Avril 2014) ainsi que le planning prévisionnel du projet qui se déroulera en GE5 (entre Septembre 2014 et Décembre 2014). Les tâches seront traitées par les deux personnes du binôme sauf pour les taches qui se déroulent en parallèle, chaque élément du binôme réalisera alors une des tâches.

Les passages du Gantt apparaissant en jaune fluo correspondent aux objectifs principaux du projet. Ce sont les livrables que nous devons donner au client à la fin du projet. Comme indiqué précédemment, priorité est donnée au prototype utilisant la reconnaissance manuelle du balisage.


Notes d'application

sujet 1

Envoi d'un mail quand une personne entre dans une zone dangereuse

sujet 2

Définition de la zone surveillée par une caméra


Bilan


Etat d'avancement

Notre programme est fonctionnel, on arrive aussi à le faire fonctionner sur le Raspberry PI mais nous ne respectons pas le cahier des charges car celui-ci a une configuration insuffisante afin de respecter le temps de réponse de 1 seconde.

Nous sommes aussi arrivés à envoyer un mail avec photo de la personne pénétrant dans une zone. Cette fonction pourrait être utile si notre système est utilisé dans un autre contexte comme celui de la protection contre le vol. Par ailleurs, lorsqu'une personne est dans la zone dangereuse, une alarme se déclenche (issue du haut-parleur de l'ordinateur).

Comme nous vous l’avons montré, notre système n’a pas un pourcentage de réussite de 100%. Ce qui est particulièrement du aux problèmes d’ombre. Avec une seule caméra, il n’est pas possible d’avoir de notion de distance.

Afin de régler ces problèmes, nous sommes convaincus que la meilleure solution est l’utilisation de deux caméras. C’est-à-dire qu’il faudrait utiliser la stéréovision afin de pouvoir faire une reconstruction 3D. Celle-ci permettrait de pouvoir supprimer les ombres du fait qu’elles seront sur le plan.


%{color:#00008B}Documents et fichiers

Programme
notice de lancement du programme
Poster

Partie IHM (réaliser par GLOAGUEN Thibault (étudiant ISIMA) ) :
Programme_ISIMA
rapport_ISIMA
présentation_ISIMA

%{color:#00008B}Perspectives

Le système que nous proposons fonctionne mais ne respecte pas toutes les contraintes imposées par le cahier des charges. Voici quelques exemples dans lesquels notre système fonctionnerait à 100% :

-Le programme pourrait être utiliser pour protéger des zones interdites. Ces zones correspondent à des endroits dans lesquels personne ne doit se trouver. Il suffirait, lors de la définition de la zone, de définir tout le champ de la caméra comme étant la zone dangereuse. Lorsqu'une personne se trouverait dans le champ (et donc dans une zone interdite) l'alarme se déclencherait. Il serait donc question de zone interdite et non dangereuse (il ne serait pas question de sécurité de personne).

-Notre programme est fonctionnel à 100% en intérieur. L'éclairage artificiel supprime en partie l'ombre des personne, mais suffisamment pour ne pas perturber le fonctionnement du programme car il est uniforme. Notre système pourrait parfaitement protéger du matériel contre le vol (par exemple).

Enfin, en terme de pistes à étudier, la stéréovision est la méthode de détection la plus indiquée pour l'environnement et les contraintes imposées par le cahier des charges. Cette technique permet, à l'aide de plusieurs caméras, de réaliser une reconstruction 3D de la scène et ainsi de supprimer (entre autres) l'ombre.


%{color:#00008B}Bibliographie

ABSOLUT Créations, (page consultée le 22/04/2014), « L’angle de champ », Adresse URL : http://www.absolut-photo.com/cours/objectif/angle.php

LOUICHE Patrick, (page consultée le 22/04/2013), « focale et angle de champ », Adresse URL : http://www.comment-apprendre-la-photo.fr/focale-et-angle-de-champ

Wikipédia, (page consultée le 22/04/2014), « Electricité Réseau de Distribution de France », Adresse URL : http://fr.wikipedia.org/wiki/%C3%89lectricit%C3%A9_R%C3%A9seau_Distribution_France

Wikipédia, (page consultée le 23/04/2014), « OpenCV », Adresse URL : http://fr.wikipedia.org/wiki/OpenCV

balisage_20140401160258_20140401160403.png (1.68 MB) axel BARRIEUX, 04/07/2021 03:24 PM

balisage-2_20140401160550_20140401160636.png (762 KB) axel BARRIEUX, 04/07/2021 03:24 PM

photo31_20140428161212_20140428161657.jpg (353 KB) axel BARRIEUX, 04/07/2021 03:25 PM

photo4_20140428161212_20140428161840.jpg (290 KB) axel BARRIEUX, 04/07/2021 03:26 PM

synoptique2_20140428130828_20140428130844.png (20.6 KB) axel BARRIEUX, 04/07/2021 03:27 PM

schema_explicatif_20140411084139_20140411084158.png (19.1 KB) axel BARRIEUX, 04/07/2021 03:37 PM

etude_theorique_20140411082708_20140411082735.png (8.36 KB) axel BARRIEUX, 04/07/2021 03:37 PM

Tableau_f_8_20140411093732_20140411093802.png (24 KB) axel BARRIEUX, 04/07/2021 03:40 PM

Tableau_f_20_20140411093732_20140411093823.png (23.4 KB) axel BARRIEUX, 04/07/2021 03:41 PM

Tableau_f_28_20140411093732_20140411093913.png (23.6 KB) axel BARRIEUX, 04/07/2021 03:42 PM

Tableau_angle_20140411093732_20140411093934.png (14.2 KB) axel BARRIEUX, 04/07/2021 03:43 PM

exemple_excel_20150111004858_20150111005104.png (19 KB) axel BARRIEUX, 04/07/2021 03:46 PM

goprocamescope_20150111004858_20150111004923.png (722 KB) axel BARRIEUX, 04/07/2021 03:47 PM

strategie_20150111171311_20150111171334.png (690 KB) axel BARRIEUX, 04/07/2021 03:49 PM

fenetre_20150110114813_20150110114838.png (105 KB) axel BARRIEUX, 04/07/2021 03:50 PM

rectangle_20150110115241_20150110115256.png (319 KB) axel BARRIEUX, 04/07/2021 03:51 PM

polygone_20150110115241_20150110115312.png (549 KB) axel BARRIEUX, 04/07/2021 03:52 PM

polygone_seg_20150110115241_20150110115326.jpg (5.79 KB) axel BARRIEUX, 04/07/2021 03:52 PM

point_20150110115241_20150110115343.png (1.16 KB) axel BARRIEUX, 04/07/2021 03:53 PM

vecteur_d_20150110115241_20150110115359.png (4.04 KB) axel BARRIEUX, 04/07/2021 03:54 PM

vecteur_t_20150110115241_20150110115417.png (4.14 KB) axel BARRIEUX, 04/07/2021 03:54 PM

Principe_algo_20150110235940_20150110235955.png (76 KB) axel BARRIEUX, 04/07/2021 03:55 PM

Tableau_algo_20150111000515_20150111000737.png (67.4 KB) axel BARRIEUX, 04/07/2021 03:56 PM

Explication_algo_20150111000515_20150111000919.png (424 KB) axel BARRIEUX, 04/07/2021 03:56 PM

Tableau_pourcentage_20150111000515_20150111000957.png (6.12 KB) axel BARRIEUX, 04/07/2021 03:58 PM

Cas_defavorable_ombre_20150111000515_20150111001122.png (454 KB) axel BARRIEUX, 04/07/2021 03:59 PM

Cas_defavorable_2_20150111000515_20150111001154.png (205 KB) axel BARRIEUX, 04/07/2021 04:00 PM

Cas_defavorable_ombre_detecte_20150111000515_20150111001306.png (318 KB) axel BARRIEUX, 04/07/2021 04:01 PM

Tableau_pourcentage2_20150111000515_20150111001349.png (6.87 KB) axel BARRIEUX, 04/07/2021 04:02 PM

hsv_20150116125306_20150119163859.png (79.7 KB) axel BARRIEUX, 04/07/2021 04:03 PM

raspberry_20150110121619_20150110121636.jpeg (44.6 KB) axel BARRIEUX, 04/07/2021 04:04 PM

WBS2_gant_20150116125306_20150116125344.png (206 KB) axel BARRIEUX, 04/07/2021 04:05 PM

planning_avant_projet_20140428141415_20140428141432.png (38.7 KB) axel BARRIEUX, 04/07/2021 04:06 PM

planning_projet_20150111003034_20150111003228.png (122 KB) axel BARRIEUX, 04/07/2021 04:07 PM

note_d_application.pdf (350 KB) axel BARRIEUX, 04/07/2021 04:08 PM

note_d_application2.pdf (449 KB) axel BARRIEUX, 04/07/2021 04:09 PM

programme.rar (43.2 KB) axel BARRIEUX, 04/07/2021 04:11 PM

notice_lancement.pdf (110 KB) axel BARRIEUX, 04/07/2021 04:11 PM

AFFICHE.pdf (1.1 MB) axel BARRIEUX, 04/07/2021 04:12 PM

projet_ZZ3F1_Gloaguen_Thibault.rar (9.95 KB) axel BARRIEUX, 04/07/2021 04:13 PM

Rapport de projet - GLOAGUEN Thibault ZZ3F1.pdf (1.01 MB) axel BARRIEUX, 04/07/2021 04:14 PM

presentation thibault gloaguen.pdf (1.33 MB) axel BARRIEUX, 04/07/2021 04:15 PM