Description de l'architecture matérielle et logicielle du projet - AndreinaW/connected-frame GitHub Wiki

Architecture matérielle

Au niveau des composants et de l'architecture matérielle, nous avons une Raspberry Pi Model B+ qui sera le coeur de notre objet connecté. Sur un des ports USB de la Raspberry viendra se brancher une carte son externe USB qui accueillera un microphone. Une alternative à ceci pourrait être de directement brancher un microphone en USB. Toujours sur la Raspberry viendra se brancher une caméra Raspberry Pi pour capturer vidéo et image.

La Raspberry sera surmontée d'une carte GrovePI+ sur laquelle viendra se brancher un capteur de luminosité. La caméra embarquée et le capteur de luminosité seront déportés dans un boitier à part.

Enfin nous disposerons d'enceintes qui communiqueront via Bluetooth avec la Raspberry. Le Bluetooth étant un protocole de communication sans-fil, nous pourrons aisément disposer nos enceintes comme bon nous semble à condition bien sûr que celles-ci soient à porter de la Raspberry.

L'accès internet se fera via Wi-Fi préférentiellement. Si jamais aucun réseau Wi-Fi n'est détecté, alors il y aura toujours possibilité de se brancher directement en Ethernet (RJ-45) qui sera alors volontairement laissé accessible.

Description logicielle

Le projet sera basé sur du traitement de son environnement, aussi bien visuel que sonore, avant de mettre à disposition les résultats au propriétaire du cadre.

Ainsi nous disposeront un logiciel embarqué sur la Raspberry directement, ainsi qu'un bus de service comportant tous les services que nous aurons nous même créés et qui pourront être réutilisés.

Notre Raspberry sera équipée OpenCV pour effectuer dans un premier temps de la détection de visage, puis par la suite de la reconnaissance de visage pour obtenir de meilleure statistiques. La communication du son en Bluetooth vers les enceintes depuis la Raspberry sera gérée via ligne de commandes (ALSA : Advanced Linux Sound Architecture) Sur la raspberry sera hébergé Nodered qui permettra de faire la passerelle (API Gateway) vers notre bus de service ou d'elle même fournir quelques fonctionnalités très simplistes ne nécessitant pas de service à part entière. Nous pourrions prendre par exemple le traitement des données provenant du capteur de luminosité.

Au niveau du bus de service nous retrouverons un serveur en python qui récupèrera les données traitées et les mettra en forme sur un site (dashboard website). Il y aura ensuite un service pour envoyer des SMS ou des mails au responsable de l'objet FramePlus pour l'avertir d'un problème de vision au niveau de la caméra. Ce même service utilisera l'API TextBelt. Nous réaliserons aussi un service qui permettra la collecte puis le traitement des données de la caméra. Ce même service fera appel à Face API de Microsoft Azure. Pour terminer, nous disposerons d'un service pour le traitement des données vocales. Il consommera des services STT (Speech to Text) et TTS (Text to Speech) d'IBM Cloud, ainsi qu'un service de recherche Web (Bing Search ?).

Voici un schéma plus représentatif de toute l'architecture :

Dataflow :