Loading...
La case départ de tous vos projets!

Mise en contexte

Le chronométrage de pilotes de motocross et une montagne de technologies interconnectées 


POURQUOI?

En 2016, le premier projet de Square One a été un logiciel permettant l'inscription en ligne pour des évènements sportifs, spécifiquement développé pour l'association de motocross Supercross Québec. Le projet races.ninja ne s'est pas avéré seulement un système d'inscriptions en ligne (incluant le paiement par carte de crédit), mais aussi tout un système permettant la gestion du déroulement des évènements en soi: inscription et vente de licences, planification des horaires, résultats durant l'évènement et résultats en ligne (après l'évènement). 

En 2017, Supercross Québec nous a demandé de connecter le système de transpondeurs qu'il venait d'acquérir avec leur système de gestion d'évènements. Nous avons tout de suite vu un défi technologique que nous ne pouvions pas refuser.


UN TRANSPONDEUR, C'EST QUOI?

Un système de transpondeurs, c'est un ensemble dans lequel on retrouve un module connecté à une ou plusieurs antennes qui émettent un signal. Lorsqu'une puce rfid est à portée du signal de l'antenne, le module reçoit l'information encodée dans la puce.
Ce genre de système est utilisé pour faire le chronométrage de courses de tous genres. Avec un petit logiciel informatique, il est simple de calculer le temps écoulé entre deux détections de la même puce, et donc d'obtenir les résultats d'une course par exemple.

R&D et chinoiseries

CONTRAINTES

Le module de transpondeurs communique seulement via un port réseau avec le protocole TCP/IP et tout le système de Races.Ninja est construit avec des technologies web tels PHP, HTML et Javascript. Nous nous doutions que la communication serait possible grâce aux récents développements dans le web concernant les websockets, mais je n'avais jamais tenté l'expérience.

Le module viens directement de la Chine, il est accompagner d'un logiciel démonstrateur en C# dont l'interface est moitié en chinois moitié en anglais. La documentation est parsemé de chinois.


DÉMARCHE
Faire fonctionner le système de transpondeur dans son plus simple état:
  1. Une antenne de connectée au module,
  2. En utilisant l'application de démonstration fournie
  3. Réussir à détecter une puce RFID (tag)

Ça n'a pas été une tâche simple, mais nous avons beaucoup appris sur le fonctionnement du système. À partir de ce moment, nous avons toute de suite commencé la reverse engineering (ingénierie inverse)  de l'application de démonstration en tentant de reproduire sont fonctionnement avec des technologies qui nous permettraient de communiquer avec la plateforme web.

La technologie clé dans toute cette expérience a sans aucun doute été NodeJS. Véritablement salvatrice du projet, NodeJS nous a permis de faire en quelques lignes de code et avec une simplicité incomparable ce que faisait l'application C# chinoise en des milliers de lignes de code. Le temps étant un enjeu important dans le projet, ce facteur n'était pas négligeable.

S'il a fallu deux jours pour comprendre comment contrôler le module avec notre petite application NodeJS, la maitrise et la compréhension du système pour en faire un système de chronométrage efficace a pris beaucoup plus de temps.

Voici un petit aperçu de notre architecture finale:

  1. Un petit serveur NodeJS est en charge de la communication avec le module via un socket TCP/IP
  2. On contrôle le serveur NodeJS via une application Javascript connectée via un autre socket (websocket). De cette manière, plusieurs interfaces peuvent être connectées en même temps.
  3. Le serveur NodeJs communique aussi avec un serveur PHP lorsqu'il détecte une puce rfid. Le serveur PHP est en charge de calculer le temps entre chaque détection et d'enregistrer dans une petite base de données le résultat. Puis ce dernier communique avec les applications de contrôle Javascript via Redis et NodeJs pour leur transmettre l'information.


Une course d'objets connectés

Est-ce qu'il y a une différence entre un test dans un environnement contrôlé et un test dans l'environnement de production (ici on parle d'une aréna remplir de terre et de motocross)? La réponse est oui, et elle est énorme!

Découvertes inattendues lors de nos premiers essais:

  1. En collant les tags sur les motocross. Les moteurs des motocross créent de l'interférences qui rend dans certains cas la détection des puces RFID impossible.
  2. En installant les tags sur les casques des coureurs. Certains modèles de casques des coureurs semblent bloquer complètement la détection des puces RFID.

Dans une course de 6 tours avec 12 participants et qui dure environ 3 minutes, nous devrions généralement détecter 72 passages. Un seul passage manqué et le coureur se retrouve dernier, car l'application ne peut pas savoir si la détection a échoué, ou si, simplement, le coureur a chuté et a donc pris plus de temps pour compléter son tour. Une surveillance humaine était donc nécessaire afin de valider les résultats.

En conclusion

Après quelques évènements dans lesquels nous avons pu faire de vrais tests, le système a atteint un taux de précision convenable de 98%. Ce taux d'erreur s'explique par des limitations technologiques en raison du modèle du module acheté par notre client et d'une certaine fragilité des puces RFID que nous avions à notre disposition. En effet, il est arrivé souvent, durant nos tests, que des pilotes chutent et endommagent la puce rfid qui était installée sur leur motocross. De ce fait, le système perdait la trace de ces coureurs et leur puce devait être remplacée.

L'expérience acquise dans le développement de cette application est par contre incalculable et nous sommes déjà à regarder des solutions pour que lors de la prochaine saison, le système puisse avoir une fiabilité de 100%. Aussi, le fait que l'application soit web nous ouvre une tonne de possibilités de fonctionnalités supplémentaires que nous prévoyons développer pour la prochaine saison.