IOT : connecter l'usine avec un Arduino - Partie 2

Coder avec l’Arduino

Choix du langage

Arduino est basé sur les langages C/C++. Il est plus aisé de coder avec ces langages sur l’Arduino, mais il est possible d’utiliser d’autres alternatives. Ainsi certains logiciels comme ardublock permettent de décrire visuellement un programme Arduino, sans avoir connaissance du langage de programmation. Cette méthode est en particulier utile pour l’apprentissage de l’Arduino de manière ludique. Aussi, il est possible d’utiliser d’autres langages de programmation (Java, python…) en utilisant des librairies capables de communiquer par l’intermédiaire des ports série de l’Arduino.

Pour notre besoin, nous avons choisi de rester sur le langage c pour plusieurs raisons:

  • La facilité de mise en œuvre, car elle est nativement supportée par l’IDE Arduino
  • La documentation plus importante et les exemples plus nombreux en langage C
  • Le langage bas niveau permettant de mieux voir les interactions entre le code et le matériel (les composants électroniques)

Environnement de développement

La plateforme Arduino est constituée du contrôleur matériel, mais aussi d’un environnement de développement, nommé Arduino IDE. Cet IDE propose de décrire nos programmes sous formes de “sketchs”.

L’IDE dispose d’exemples typiques de sketchs Arduino et propose également l’import de librairies pour communiquer avec les composants électronique les plus courants.

Enfin, l’IDE détecte la carte Arduino branchée en USB sur votre poste, afin d’installer le sketch compilé sur la carte, une fois le développement terminé. L’intégration est simple, en un click et quelques secondes d’attente, le sketch peut être testé sur l’Arduino !

Un sketch est en fait un programme C constitué de 2 méthodes principales : setup() et loop()

Vous l’auriez compris, setup() initialise le programme et les composants utilisés. Tandis que loop() est une boucle principale qui contient la logique du programme.

Vous l’avez deviné, on n’utilise ici aucune programmation événementielle, on utilise simplement la boucle principale ! C’est old school et très basique.

Les pièges dans le code

  • Le langage

Le langage est sans doute la 1ère difficulté rencontrée. De nos jours, nous utilisons des langages de plus en plus haut niveau, avec plusieurs couches d’abstractions, qui nous habituent à un code concis et efficace. Là, en langage C, c’est plus laborieux. Il faut déjà mettre à jour nos connaissances sur le langage, et les algorithmes qui semblent simples sur le papier sont plus compliqués à mettre en œuvre. Je ne souhaite pas critiquer le langage C en faveur d’un autre langage, mais je sais que l’adaptation au langage C depuis un langage haut niveau (Groovy,JavaScript,etc) est difficile.

  • La communication avec les composants électroniques

Les composants électroniques utilisent des standards de communication bien établis et constituent une difficulté majeure. Par exemple, le composant RFID émet un code en une série de bits, qu’il faut décoder selon un standard bien précis : l’interface wiegand. Finalement, nous avons repris du code existant pour décoder ce standard. Voici la méthode en question, ce qui vous fera découvrir ou redécouvrir les joies du langage C !

 

void recevoirCodeRFID()
{
unsigned char rxByte;
rxByte = RFID.read();
if (tagComingFlag == 0 && rxByte == 0x02) {
tagRX[tagCounter] = rxByte;
tagComingFlag = 1;
tagCounter++;
else if (tagComingFlag == 1) {
tagRX[tagCounter] = rxByte;
tagCounter++;
if (tagCounter == 14)
{
tagCounter = 0;
tagComingFlag = 0;
tagRecdFlag = 1;

while (RFID.available()>0){
RFID.read();
}
stopMethod = true;
}
else {
tagComingFlag = 0;
tagCounter = 0;
}
}

En bref, la méthode détecte l’arrivée d’un octet signalant le début de la transmission du code RFID (ce code de début est 02). Puis on lit octet par octet le code entier. Une fois le code entier lu (14 octets), on vide le buffer du composant avec une série d’appels à read().

  • La gestion du temps

Notre Arduino a pour but d’envoyer des données d’activité de l’utilisateur, et a besoin de dater chaque activité utilisateur avant de l’envoyer sur le cloud. Mais comment avoir accès à la date et l’heure depuis un Arduino ?

Dans un sketch Arduino, on a bien accès à une méthode getMillis(), qui donne le temps écoulé depuis le début du programme ! C’est utile pour avoir un écart de temps, mais insuffisant pour avoir une date complète, avec le jour et le mois. La solution que l’on a trouvée, nous est fournie par le système linux embarqué sur le contrôleur yun. A chaque démarrage du système, à condition que la carte ait accès à un Wifi, le système synchronise la date avec le protocole NTP, rendant disponible la date dans notre programme.

Dans ce cas, un simple appel au système linux de l’Arduino suffit :

 

void recupererDateCourante() {
p.begin(« sh »);
p.addParameter(« /sketchArduino/dateCourante.sh »);
p.run();

dateCourante = «  »;
int i =0;
while( p.available() > 0) {
char c =p.read();
if(i<=18) {
dateCourante +=  String(c);
}
i++;
}
}

 

Le debugging

Debugger avec l’arduino n’est pas forcément aisé, dépendamment de l’IDE que vous utiliserez. Ayant utilisé seulement l’Arduino IDE de la fondation Arduino, cet IDE ne permet pas le debug. Nous avons donc utilisé l’écriture dans la console avec les Serial.print() !

Mais d’autres IDE proposent le debug de l’Arduino, comme VisualStudio. Donc, avant de vous lancer dans un projet Arduino, choisissez avec attention l’IDE que vous utiliserez, cela peut s’avérer décisif ! A noter également que le monde Arduino est récent, ainsi les IDE proposant des fonctionnalités évoluées comme le debug vont certainement devenir de plus en plus courantes.

Architecture logicielle

Dans notre cas, l’Arduino sert à récupérer 2 informations : le badge d’un utilisateur et sa présence sur le poste de travail. Ces informations sont remontées par services REST à une base de données noSQL.

Voici le schéma représentant l’architecture de notre système.

lecteur rfid

Cette architecture permet de rendre « connecté » cet objet, car il est relié en temps réel à cette base de données. Notre objet enregistre une session de travail, caractérisée par une identification utilisateur (le badge) et le temps de présence de cet utilisateur sur son poste de travail.

A chaque fois que la session de travail est terminée, c’est-à-dire quand l’utilisateur a quitté son poste, l’information de session de travail est envoyée sur le réseau.

Cette session de travail est un simple objet JSON, contenant les caractéristiques suivantes :

  • Identification du badge
  • Date et heure de début de la session de travail
  • Date et heure de fin de la session de travail

Restitution des données

Maintenant que nos sessions de travail sont enregistrées dans la base de données, on peut en faire ce que l’on veut et les restituer sur des interfaces diverses et variées. Dans notre cas, le but était de les afficher sur une application Android et aussi sur un dashboard kibana.

L’application Android cible les utilisateurs des postes de travail, afin qu’ils puissent visualiser leur temps de travail sur les postes pénibles. Ils peuvent ainsi parcourir le temps passé selon une période de temps. Le dashboard Kibana est plutôt destiné à des équipes RH, afin d’avoir une visualisation plus globale du temps passé par tous les employés sur les postes pénibles.

Voici les captures d’écran de l’application Android telle qu’elle a été implémentée (les critères type de pénibilité et type de machine ne sont pas implémentés).

Dashboard Kibana 2 dashboard kibana 1

Conclusion

 

Cette étude nous a permis de monter en compétences sur un certain nombre de technologies liées à l’IOT (microcontrôleur, hardware, capteurs…). Nous avons surtout réalisé qu’un projet IOT englobe un nombre important de technologies et qu’il est intellectuellement enrichissant de travailler dessus. En effet, nous avons aussi bien fait de la conception 3D, du montage électronique ou bien encore des bases NoSQL, ce qui forme une stack complète.

Malgré quelques erreurs, nous sommes parvenus à réaliser un boitier DIY qui permet de comptabiliser le temps de présence sur un poste pénible.

L’étape suivante sera de prendre en compte plus largement l’environnement du poste de travail dit « pénible » (objets lourds, température, bruit, toxicité…). A ces fins, d’autres pistes de mesures peuvent être explorées comme la mesure avec des objets connectés portés par l’employé (wearable) ou bien par les outils manipulés (un objet lourd, un outil dangereux, etc).

L’IOT est un vaste domaine en plein expansion mais accessible tout à chacun pour une mise de départ faible. Alors n’hésitez pas et lancez-vous !

 

Auteurs : Vincent Piard, Expert Technique, SQLI Nantes et Aurélien Fourmi, Expert Technique, SQLI Nantes

0 commentaires

votre commentaire

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Inscription newsletter

Ne manquez plus nos derniers articles !