Introduction

Le week-end dernier (23-35 mars 2018) avait lieu chez Versusmind un grand hackathon interne sur le thème de la santé. Tous les détails ici

A l’occasion de ce hackathon, ce n’est pas moins de 27 Versusiens qui ont planché par équipe sur 4 projets d’innovation dans le domaine de la santé. Ce billet de blog vous présente l’un de ces projets : EhpadGo.

L’histoire de ce projet est un peu particulière car contrairement aux autres, il n’a pas été apporté par un porteur de projet issu du domaine de la santé mais est issu directement de l’équipe et d’une expérimentation menée par Amazon : le magasin sans caissier Amazon Go.
>> Voir la vidéo Amazon Go <<

Les technologies annoncées : capteurs, computer vision et Machine learning. Que des sujets qui nous parlaient déjà et surtout un challenge : que serions nous capable de faire avec nos moyens en un week-end ?

Le sujet est donc né de la technologie mais les applications sont nombreuses à partir du moment ou il y a une gestion automatisée de stock à faire : industrie, commerce, santé. Le cas étudié pour le hackathon est celui des Ehpad : les employés de ces établissements sont souvent en effectif limité et doivent gérer tous les aspects logistiques en plus de s’occuper des résidents. Notre but à donc été de les libérer de l’aspect suivi et gestion du stock. L’idée d’EhpadGo était née.

La Cinématique

Voici la cinématique de l’expérience utilisateur :

1. L’utilisateur se présente à la porte sécurisée pour entrer dans le stock
   a. Il présente badge pour entrer
   b. Une photo est prise et analysée avec le système de reconnaissance faciale pour valider l’accès
   c. Une fois son identité validée, la porte s’ouvre pour le laisser entrer
   d. Sa session est créée dans le système avec une gestion de panier

2. L’utilisateur prend ou repose des produits sur les étagères du stock
    a. Les étagères sont équipées de capteurs de poids et envoient toute variation dans le système qui est capable d’y associer une modification du stock en live. Chaque étagère est gérée indépendamment, avec un poids unitaire du produit posé dessus. Ainsi pour une variation de 500g sur une étagère dont les produits pèsent 250g, le système déduis que 2 produits ont été pris et le stock est mis à jour en temps réel.
    b. Lorsqu’un changement intervient sur le stock, une caméra située sur l’étagère en question photographie la personne qui a effectué l’action afin de l’identifier et ajouter les produits à son panier. En effet il parait logique que plusieurs personnes puissent être présente au même moment dans le stock et nous avons besoin de savoir qui a pris quoi pour le suivi d’inventaire.

3. L’utilisateur sors du stock avec ses produits
   a. Il badge pour ouvrir la porte
   b. Le système clos alors sa session et lui envoi un e-mail récapitulatif de son passage. Cela permet notamment d’ajouter une garantie de sécurité en cas d’usurpation d’identité et de confirmer à l’utilisateur que le système a bien identifié les produits qui ont été prélevés.

Architecture globale

Lorsque nous avons réfléchi à l’architecture à mettre en place, nous avons cherché comment concevoir une solution qui remplisse tous les critères ci-dessus en terme fonctionnel mais nous avons aussi pris en compte le fait que pour être viable, la solution devait être :
– Facilement déployable, techniquement comme humainement
– Adaptable à un tout petit stock type Ehpad ou immense type dépôt de centrale d’achat
– Scalable
– Abordable financièrement

Ce dernier point était d’ailleurs particulièrement déterminant car si Amazon semble utiliser l’analyse de la vidéo en continu pour suivre les gens, la solution n’est pas viable financièrement pour être diffusée de façon large vu le coût que cela implique. Nous avons donc du faire des choix et après avoir challengé les différentes API cognitives de Microsoft nous avons choisi la Face API qui nous permet de renseigner une base de visages avec leur identité afin de pouvoir ensuite les identifier à partir d’une photo.
Cette solution nous a permis de réduire de beaucoup le nombre d’appel au service afin de rester dans des coûts maitrisés.

Un autre point qui nous a permis de limiter les coûts a été l’utilisation de RaspberryPi et d’Arduino pour les installations de contrôle d’accès et au sein du stock pour les capteurs de poids et de caméra.

Pour les aspects scalabilité et facilité de déploiement, la solution tout entière, hormis le matériel installé physiquement se base intégralement sur une architecture micro-service serverless basée sur les Azure Functions , l’utilisation du Service Bus et une base de données CosmosDB. Tous ces éléments sont conçus pour pouvoir scaler et être géo-répliqués et sont donc parfait pour ce type de solutions.
Pour la facilité de déploiement enfin, l’utilisation de queues sur le Service Bus d’Azure nous permet de rajouter des étagères (ensemble capteurs de poids & caméra) à l’infini. En effet chaques arduino et raspberri de chaque étagère communique avec le système par la même queue et un système de tag permet de filtrer et diriger les messages vers la bonne étagère. Ainsi rajouter une nouvelle étagère peut se faire sans autre opération sur le système que de la déclarer dans la base de données et sur un fichier de configuration des Raspberry et Arduino.

Stack Technique

La partie service, dans le cloud Azure repose donc sur un ensemble de functions Azure, codées en C# et utilisant la partie API manager pour les interractions avec le backoffice principalement et des queues du Service Bus pour les communications entre les functions et les installations physiques.
Les Raspberry Pi que nous avons utilisé pour le contrôle à l’entrée et pour l’identification de la personne au niveau des étagères utilisent des programmes ecris en Python et les arduino chargés de gérer les capteurs de pesée font tourner un programme en C++.
Les API de reconnaissance faciale des Cognitives Services Microsoft sont exploitées avec les librairies dédiée Python et l’envoi de mail récapitulatif utilise le service SendGrid via son API REST.

Détail de l’implémentation

Cinématique 1 : Entrée dans le local

A l’entrée, dans le local, la cinématique est déclenchée par l’utilisateur présentant son badge sur le lecteur. Cela déclenche la prise d’une photo pour une double authentification.
Une fois l’authentification validée, l’utilisateur est libre d’entrer et une demande de création de session est envoyée dans la queue et sera alors traitée quasi instantanément par la function dédiée.
Une session contient les informations de l’utilisateur, sa date et heure d’entrée et une liste de produits vide.

Cinématique 2 : ajout/suppression de produits au panier

Cette cinématique est la plus complexe car elle représente la partie la plus innovante du processus : comment détecter automatiquement les produits prélevés par les utilisateurs sans que cela ne leur demande une autre action que celle de s’emparer des produits ?

Voici le détail de cette cinématique :
1. L’arduino qui gère les capteurs de poids détecte une modification du poids sur une tablette et envoi un message dans la queue pour signaler l’événement. Les informations envoyées sont l’identifiant de la tablette concernée, la nouvelle mesure et l’ancienne. Afin de limiter les traitements un premier filtre a été codé afin d’éliminer des variations trop faibles qui seraient dues à des légère perturbations.
2. Le message dans la queue est traité par la function abonnée à cet événement.
3. La function récupère les informations du produit associé au produits présent sur la tablette en question, dont le poids unitaire, et calcul le nombre de produits prélevés/déposés et met à jour le stock en temps réel
4. Un message est déposé dans une autre queue afin de demandé au(x) Raspberry de la zone de prendre une photo de la personne devant la tablette
5. Le(s) Raspberry(s) concerné traite le message et déclenche la prise de photo
6. La photo est transmise à l’API Face afin d’identifier la personne dans les personnes présentes
7. Un appel à l’API de mise à jour de session est effectué afin d’associer les produits prélevés au panier de l’utilisateur
8. L’API transmet l’appel à la function
9. La function récupère la session en cours de l’utilisateur et effectue la mise à jour

Nous avons volontairement fait le choix de placer la gestion des capteurs de poids et la prise de photo sur des appareils distincts afin de tester les performances du système de queues d’Azure dans l’optique de pouvoir avoir un système plus distribué. L’action de prendre la photo, déclenchée par le changement de poids doit donc transiter de l’arduino par le cloud avant de redescendre vers le Raspberry.
Cela permet d’anticiper une évolution de la solution. En effet dans le cadre du Hackathon, nous avons prototypé une seule étagère, avec deux tablettes et une caméra. Le problème qui se pose est qu’une seule et unique caméra ne permet pas d’identifier un utilisateur dans tous les cas. Si celui-ci ne fait pas face à la caméra la reconnaissance est compromise.

La solution de passer par des queues permet de prévoir plusieurs caméra, installées sous plusieurs angles pour renforcer les chances d’identification. Cela permet aussi d’adapter la solution à tout type de disposition matérielle tout en impactant au minimum le code source.

Il s’est avéré selon nos tests que les temps de transmission depuis l’envoi de la mesure de poids par l’arduino à la réception de l’ordre de prise de photo, restait généralement sous les 0,5s ce qui nous a paru acceptable dans la majorité des scéanarii. Des tests plus poussés seront bien sûr à envisager dans le cas d’une mise en production mais les résultats obtenus nous ont globalement satisfait.

Cinématique 3 : Sortie du local et fin de la session

La sortie du local est finalement la cinématique la plus simple : l’utilisateur badge pour sortir. Un message de demande de fermeture de la session. Il est immédiatement libre de sortir pendant que la function dédiée clos la session, en enregistrant la date et l’heure de sortie.
Un e-mail récapitulatif est alors envoyé contenant la date et heure de l’entrée, la durée de présence et le détail des produits enregistrés. Cela fait office de justificatif et permet par la même occasion de garantir une protection supplémentaire contre l’usurpation d’identité et le vol de matériel puisque la personne est immédiatement avertie.

Bilan et perspectives

Au final, nous avions démarré ce week-end de hackathon sans aucune certitude de pouvoir atteindre un résultat fonctionnel et le fait d’avoir pu relever tous les défis que nous nous étions fixés, avec en prime une solution financièrement abordable est une grande satisfaction pour toute l’équipe.

Vous trouverez ci-dessous la vidéo de la démo de l’application tournée en toute fin de hackathon :

>> La démo, en vidéo <<

La solution est bien sûr perfectible à de nombreux égards mais le POC est intégralement fonctionnel et les tests menés lors de ce Hackathon nous permettent aujourd’hui de savoir quelles sont les technologies à mettre en œuvre, leurs performances et leur degré de maturité.
En termes de perspectives, les usages sont bien entendu nombreux car ils sont applicables à de très nombreux scénarii dans de nombreux domaines métiers. L’avenir nous dira ou ce projet nous mènera !

Un grand merci à toute l’équipe Versusmind d’avoir répondu présent à ce hackathon et plus particulièrement à mon équipe de tueurs d’élites du code 🙂  Je vous laisse sur ces belles paroles avec quelques photos du week-end et de l’installation de notre projet, afin que vous puissiez juger vous-même de nos qualités de bricoleurs de l’extrême.