[Data Rider] Booster Mario Kart à l’IoT et à l’IA – Etape 2 : la donnée en temps réel, du capteur au Dashboard

Dans un précédent article, nous vous présentions notre projet Data Rider, le circuit de voiture électrique amélioré de capteurs en tout genre visant à collecter les données des voitures en temps réel (vitesse, position, consommation moyenne, sortie de piste, etc.). L’objectif ? Créer une expérience de jeux digitale innovante ! Aujourd’hui, je vais vous présenter le prototype et les outils qui nous ont permis de réaliser la première étape de ce démonstrateur. Ensuite, je vous expliquerai les problématiques de temps réel que l’on a rencontrées et la suite du projet…

Les objectifs du démonstrateur

A travers la réalisation de ce projet, c’est toute la chaîne de la donnée qui est exploitée et analysée. Les résultats sont affichés dans des Dashboards (misez sur le Dashboard Design), au travers d’un ensemble d’outils IT et de Framework.

C’est une formidable vitrine de notre savoir-faire en interne, auprès de nos clients et prospects. C’est aussi un outil pédagogique accessible à tous, qui permet de rendre la compréhension des enjeux et du traitement de la donnée simple et claire.

Pour y parvenir, la première étape a été la réalisation du prototype IoT de récupération de la donnée.

A travers la réalisation d’un projet créé dans un univers ludique pour en faciliter la compréhension, c’est toute la chaîne de la donnée qui est exploitée et analysée.

La réalisation du prototype

La réalisation du prototype a nécessité une phase de recherche et développement pour s’assurer que la collecte des données d’ampérage, de voltage et de positions était récupérable dans un dispositif électronique, puis transmissible à un ordinateur.

Le principe de fonctionnement :

L’état des capteurs est lu grâce à une carte à microcontrôleur Arduino et l’ensemble des données est envoyé à un ordinateur via une liaison USB.

Les capteurs de positions sont répartis tout au long du circuit.

Les capteurs de position sont des capteurs magnétiques (dit à effet Hall) qui détectent le passage d’un aimant. C’est une détection en tout ou rien. Chaque véhicule est équipé d’un aimant.

Les capteurs d’ampérage et de voltage sont connectés aux pistes du circuit pour mesurer la tension et l’ampérage.

Le capteur d’intensité est un circuit spécialisé qui mesure le courant par effet hall (même principe que le capteur de position, mais l’utilisation est différente).

Chaque piste est équipée de 8 capteurs de position répartis sur l’ensemble de la longueur du circuit, d’un capteur d’ampérage et d’un capteur de voltage.

Le cœur du système électronique est une carte à microcontrôleur. Ici, la marque utilisée est Arduino.

Un microcontrôleur est un circuit intégré programmable contenant un microprocesseur, différents types de mémoires en faibles quantités et des périphériques de communication (entrées sorties).

Il est adapté pour les systèmes embarqués, en termes de consommation énergétique, coût et puissance. C’est une sorte de nano ordinateur.

Ce système se programme grâce à un IDE (Integrated Development Environment) open source, dans un langage informatique proche du C.

Pourquoi avoir opté pour le langage C ? Tout simplement parce que c’est un langage de bas niveau qui permet de gérer l’ensemble des ressources système de façon optimisée en mémoire et temps de traitement (à l’opposé d’un langage Python par exemple qui lui sera plus gourmand en ressources et temps de traitement).

Voici un screen de l’IDE de programmation Arduino.

Le programme doit être téléchargé dans la mémoire de la carte pour être actif.

Ensuite, dès que la carte est alimentée ou qu’un reset est effectué, le programme principal s’exécute en boucle.

Le montage du dispositif électronique

L’ensemble du dispositif électronique a été intégré à une table pliable afin de rendre le démonstrateur facilement transportable.

L’installation du circuit, des capteurs et autres dispositifs a nécessité la conception de pièces spécifiques faites grâce à l’impression 3D (cela fera l’objet d’un article dédié ).

Ceci a permis d’avoir un prototype fiable et robuste pour l’acquisition des données.

A noter que dans la conception en impression 3d, des logiciels open source ont aussi été utilisés :

• Le logiciel de modélisation : Blender
• Le logiciel de slicing : Cura 5

Les problématiques de flux de données en temps réel

Voici le principe de fonctionnement des flux de données jusqu’à l’ordinateur.

Les signaux électroniques sont captés par le code Arduino (boucle de code infinie), qui les envois sur un port USB. L’ordinateur se charge de la récupération grâce à un script Python.

Lors des différents essais en conditions réelles, il est apparu que nous perdions de la donnée.

En effet, durant l’acquisition des données, certaines détections de position étaient tout simplement absentes dans le fichier de données. Voici ce que l’on aurait dû observer en schéma simplifié :

Nous aurions dû observer un nombre de détections par capteur sensiblement identique, ou du moins proportionnel à la vitesse du véhicule.

On voit sur le schéma, par exemple, que pour le capteur 254, la mesure a été prise et lue 5 fois lors du passage du véhicule devant.

Voici ce qui a été observé en schéma simplifié :

L’observation du fonctionnement en conditions réelles, laisse voir des manques de données des capteurs de positions.

Voici l’analyse d’un fichier de données réelles de déplacement des véhicules sur le circuit générés à partir du programme python de réception.

Analyse d’un fichier de 12 tours de circuit sans mesure de l’ampérage

Le 1^er constat est que la mesure des différents capteurs n’est pas homogène. Certains capteurs captent beaucoup plus d’occurrences que d’autres. La vitesse de déplacement joue un rôle mais ne permet pas à elle seule d’expliquer des écarts du simple au double.

La valeur 255 correspond à une absence de détection, d’où le nombre élevé de détections.

Analyse d’un fichier de 12 tours de circuit avec mesure de l’ampérage

Dans ce fichier avec mesure de l’ampérage, on constate une très forte diminution de l’occurrence des mesures des capteurs de position et des mesures en général.

Il a surtout durant été remarqué durant les phases de tests que le calcul de l’ampérage était fortement gourmand en temps de traitement (environ 40 ms seconde), ce qui empêchait la récupération des mesures de certains capteurs de position.

La finalisation de la 1ére étape du démonstrateur a mis en lumière les problématiques de temps réel et de la récupération de la donnée de manière fiable et entière.

Actuellement, une phase d’exploration de la donnée est en cours avec la mise en place d’un protocole de Tests sur l’ensemble des paramètres qui peuvent impacter le temps de réponse du système et empêcher sa fiabilisation.

Parmi les paramètres à étudier, se trouvent :

• Le Baud (vitesse de transmission entre la carte électronique et l’ordinateur)
  Plus le baud est rapide et plus le risque d’erreur est grand.
• L’optimisation du code Arduino pour gagner en vitesse de traitement aval
• L’optimisation du code Python pour gagner en vitesse de traitement amont, voir l’utilisation d’un nouveau langage plus bas niveau, comme RUST.

Data Rider : de l’optimisation à la prochaine étape du projet

Des tests d’optimisation sont en cours actuellement, et plusieurs solutions sont à l’étude (décentralisation de l’ampérage sur un autre Arduino, utilisation de Rust à la place de python pour gagner en rapidité, utilisation d’un modèle de puissance en fonction du temps pour la puissance, etc.)

En parallèle, nous avons déjà commencé la phase 2. Cette étape doit permettre d’ingérer les données via Kafka, puis de les traiter avec Spark, de les stocker dans une base de données et, enfin de les afficher dans un Grafana). De plus, la phase 3, qui consiste à piloter un véhicule avec une intelligence artificielle est également en cours.

À suivre 😉

👉 Retrouvez toute notre actu en temps réel en nous suivant sur LinkedIn 👈