Les interfaces SPI et I²C ont le bon goût d’épargner au concepteur l’essentiel du conditionnement requis pour les signaux allant d’un capteur à un microcontrôleur. Les capteurs modernes clé en main délivre en effet des données pré-encapsulées via un bus série normalisé. Le hic est que bon nombre de ces capteurs sont destinés aux bonnes œuvres des smartphones et autres dispositifs portables, et sont donc dans des boîtiers minuscules ou BGA difficiles à souder à la main (cf. encadré Le problème des BGA). Pour une production en petite série, recourir à des cartes d’évaluation « prêtes à l’emploi » dotées d’un microcontrôleur et de tous les capteurs possibles serait un non-sens économique. Les cartes d’extension Berry offrent une bien meilleure solution.

 

Le problème des BGA
Même les sous-traitants les plus expérimentés peinent parfois à placer et souder correctement les composants en boîtier BGA. Tam Hanna a récemment utilisé un capteur d’humidité HDC2010 de Texas Instruments logé dans un de ces minuscules boîtiers. Parmi le lot de cinq cartes utilisant la puce, trois étaient défectueuses et ont dû être renvoyées en Chine pour être réassemblées. Il est donc recommandé de demander au prestataire un contrôle supplémentaire aux rayons X. Le surcoût est moindre et diminue le risque de recevoir une carte défectueuse.






 

La famille Berry a la tête en bas

Car, oui, Ozzmaker, le fabricant des cartes Berry, est australien. Nous nous intéresserons ici à deux de ses cartes à centrale inertielle, la BerryIMU et la BerryGPS-IMU (fig. 1).

Berry boards: BerryGPS-IMU (right) and BerryIMU (left)
Figure 1. La carte BerryGPS-IMU (à droite) est plus grande et plus chère que la BerryIMU.

Les capteurs des puces modernes ne sont en général adressables que sur un nombre limité d’adresses I²C afin d’augmenter la densité des broches de la puce. Ceux de la carte BerryIMU (tableau 1) offrent deux options d’adressage.

Tableau 1. Cartes et fonctions

Cartes Capteurs
LSM6DSL Accéléromètre et gyroscope
LIS3MDL Magnétomètre
BMP388 Capteur de température et de pression








Les adresses I²C se configurent par application d’une goutte de soudure sur des cavaliers placés sur le côté cuivre de la carte (fig. 2). Les cartes acceptent aussi bien l’alimentation 3,3 V d’un Raspberry Pi que les 5 V du monde Arduino. La carte BerryIMU-v3 peut également être configurée en mode SPI en appliquant une goutte de soudure sur le cavalier JP7.

I2C address selection is made via drops of solder.
Figure 2. Sélection d’adresse I²C par soudure : simple, robuste et à l’épreuve des vibrations.

J’ai trouvé particulièrement amusante la façon de relier la carte IMU à un Raspberry Pi à l’aide d’un câble et d’un adaptateur Qwiic (fig. 3). Heureusement, car je savais que l’interfaçage entre une carte Berry et un Raspberry Pi peut revenir à faire avaler des épinards à un enfant. L’adaptateur Qwiic est un connecteur femelle à 2x3 broches qui s’enfile sur les 6 premières broches GPIO du RPi. La connexion est facile, il faut juste veiller à ce que le connecteur JST de l’adaptateur soit orienté vers l’extérieur du RPi (un modèle 4B dans mon cas).

 This adapter fits to the GPIO port
Figure 3. L’adaptateur Qwiic s’embroche sur le port GPIO du Raspberry Pi.

1 – 2 – 3,14 – test

Une façon simple de détecter les périphériques présents sur un réseau local est d’utiliser l’outil nmap (Network Mapper). On trouvera ainsi le ou les RPi avec la commande nmap -sP 192.168.1.1/24.

Le RPi est détecté, la carte Berry connectée, comment tester les capteurs ? En ouvrant d’abord l’excellente documentation du site Ozzmaker. Plusieurs scénarios y sont décrits, et un code d’exemple est disponible sur GitHub. Le client git est installé par défaut sur les dernières versions de Raspberry Pi OS (ex-Raspbian), ce qui permet de récupérer le code avec :
 

pi@raspberrypi:~ $ git clone http://github.com/ozzmaker/BerryIMU.git

 

Pour un premier essai de lecture des données, le programme berryIMU-simple.py du dossier python-BerryIMU-gyro-accel-compass convient. On le lance avec :

 

pi@raspberrypi:~/BerryIMU/python-BerryIMU-gyro-accel-compass $ python3 berryIMU-simple.py

 

Voici une réponse typique :

 

Found BerryIMUv3 (LSM6DSL and LIS3MDL)

Loop Time  0.02 #  ACCX Angle 173.62 ACCY Angle 179.06  #        # GRYX Angle  0.08  GYRY Angle -0.03  GYRZ Angle  0.02 #             #  CFangleX Angle 104.20   CFangleY Angle 107.43  #          # HEADING 303.92  tiltCompensatedHeading 313.31 #

 

Jeter un œil au code est toujours intéressant. On y découvre d'abord que le programme utilise les fonctions du module IMU pour détecter le matériel :

 

IMU.detectIMU()

if(IMU.BerryIMUversion == 99):

   print(" No BerryIMU found... exiting ")

   sys.exit()

IMU.initIMU()

 

Ensuite que les données des capteurs sont lues dans une boucle infinie avec les fonctions du module IMU, puis stockées dans des variables :

 

while True:

   ACCx = IMU.readACCx()

   ACCy = IMU.readACCy()

   ACCz = IMU.readACCz()

   GYRx = IMU.readGYRx()

   GYRy = IMU.readGYRy()

   GYRz = IMU.readGYRz()

   MAGx = IMU.readMAGx()

   MAGy = IMU.readMAGy()

   MAGz = IMU.readMAGz()

 

Ce programme est un exemple classique de modularisation d’une application Python. Le module IMU qu’il importe (IMU.py) appelle ainsi à son tour la bibliothèque externe smbus pour fournir au RPi les fonctions de communication avec le bus I²C :

 

import smbus

bus = smbus.SMBus(1)

from LSM9DS0 import *

from LSM9DS1 import *

from LSM6DSL import *

from LIS3MDL import *

import time

Des capteurs faciles à capter

Comprendre le mode d’interaction de ce type de capteurs ne représente qu’une petite partie du travail restant, mais il suffit souvent d’avoir épluché la fiche technique de l’un d’eux, p. ex. celle d’un gyroscope, pour vite comprendre le fonctionnement du capteur d’un autre fabricant.

Le niveau supérieur, celui du traitement des données et de leur représentation graphique, peut s’avérer plus délicat. Dans le cas des cartes Berry, la documentation fournit toute l’aide nécessaire. Le manque de place m’oblige à vous renvoyer au site d’OzzMaker pour des exemples de tels traitements avec le RPi, p. ex. avec la version gratuite du logiciel Mathematica.

The field information returned by the compass
Figure 4. Signature graphique d’un magnétomètre non calibré (source : ozzmaker.com).

Mathematica est notamment utilisé dans le tutoriel décrivant le calibrage du magnétomètre de la carte BerryIMU. La figure 4 en est extraite. L’auteur explique que la forme elliptique de ce nuage de points est caractéristique de la distorsion d’un champ magnétique uniforme en présence de matériaux ferromagnétiques ou du champ magnétique terrestre lui-même. Il explique ensuite que la proximité d’un aimant permanent aurait donné un nuage de points circulaire, mais non-centré sur l’origine des axes. Le site est parsemé de ces petites touches pédagogiques toujours bienvenues.

La famille Berry a la tête en l’air

C’est un drone de drame que pourrait vivre la carte BerryIMU si vous l’embarquiez dans un tel engin. Car l’adaptateur Qwiic (fig. 3) qui la relie au RPi ne résisterait sans doute pas aux vibrations d’un drone. C’est un bête problème de ceinture de sécurité, me direz-vous. Certes, mais il y en a un autre : la BerryIMU ne fournit pas de données GPS.

La famille Berry compte heureusement un pro de la géolocalisation : la carte BerryGPS-IMU. Pour l’utiliser il faut d’abord souder un connecteur 2x5 contacts, ce qui ne devrait guère poser de problème malgré la proximité de deux condensateurs CMS de découplage (voir aussi Pourquoi souder à la main ?).
 

Pourquoi souder à la main ?
Le montage des connecteurs mâle et femelle pose de gros problèmes aux machines. Même le fabricant MicroChip aurait rencontré des problèmes d’assemblage automatisé lorsqu’il a ajouté des microcontrôleurs compatibles Arduino à sa gamme de produits.







La carte se monte sur le RPi (hors tension !) au moyen de quatre écrous et boulons fournis. Comme la position des trous a été prévue pour le RPi Zero, je n’ai pu en utiliser que deux sur mon RPi 4, et la carte Berry s’est retrouvée en station bipède (fig. 5).

Target platform
Figure 5. Le RPi 4 n’est à l’évidence pas la plateforme cible.

Une fois la carte montée, un scan du bus I²C avec la commande i2cdetect devrait retourner le même résultat qu’avec la BerryIMU puisque les deux cartes partagent les mêmes capteurs, hormis bien sûr un module GPS (uBlox) supplémentaire pour la BerryGPS-IMU.

Sur le côté de la carte, un sélecteur à deux positions permet de choisir entre l’antenne interne intégrée et une antenne externe. Visible à mi-hauteur de la carte, le disque métallique n’est pas une pile bouton mais un super-condensateur. L’énergie qu’il stocke permet de garder un certain temps en RAM les éphémérides des systèmes de satellites. Ces données permettent au récepteur GPS d’être rapidement opérationnel après une brève mise hors tension.

Le module GPS et l’ordinateur hôte communiquent par port série, ce qui peut poser problème avec le RPi en raison de petites incohérences entre certaines versions du noyau Linux. Il est donc recommandé de mettre à jour Raspberry Pi OS avant d’utiliser la carte :

 

pi@raspberrypi ~ $ sudo apt-get update

pi@raspberrypi ~ $ sudo apt-get upgrade

pi@raspberrypi ~ $ sudo reboot

 

Le port série du RPi est par défaut affecté à la console. Pour le libérer on lance raspi-config, on sélectionne Interfacing Options -> Serial , on répond No à la question Would you like a login shell to be accessible over serial?, puis Yes à la question Would you like the serial port hardware to be enabled?. On contemple avec satisfaction le message de la figure 6, puis on redémarre le RPi pour que la nouvelle configuration soit prise en compte.

Output from raspi-config
Figure 6. Message de sortie de raspi-config confirmant l’activation de l’interface série.

Affichage des données GPS

Pour visualiser depuis le terminal les données fournies par le module GPS, on entre la commande suivante :
 

pi@raspberrypi:~ $ cat /dev/serial0

$GPGSV,1,1,00*79

$GLGSV,1,1,00*65

$GNGLL,,,,,,V,N*7A

$GNTXT,01,01,01,NMEA unknown msg*46

 

Les données sont au format NMEA, un protocole aux trames relativement simples à analyser. Vous pourriez écrire votre propre parseur (analyseur) pour extraire toutes les informations du flux de données GPS, mais Linux, en bon système d’exploitation universel qu’il est, fournit déjà tout ce qu’il faut pour l’accès aux données GPS et à leur traitement.

L’outil charnière est pour nous gpsd, un démon qui reçoit et traite les données du récepteur GPS en arrière-plan et les envoie à des programmes tiers de visualisation des données tels que les clients gpsmon et cgps. Ces trois outils sont compris dans le paquet GPSD et s’installent avec :
 

pi@raspberrypi:~ $  sudo apt-get install gpsd-clients gpsd -y

 

Le fichier de configuration de gpsd doit être modifié afin que le démon utilise le bon périphérique série. On ouvre le fichier avec (p. ex.) l’éditeur pico :
 

pi@raspberrypi:~ $ sudo pico /etc/default/gpsd


On repère le bloc Devices :
 

# Devices gpsd should collect to at boot time.

# They need to be read/writeable, either by user gpsd or the group dialout.

DEVICES=""


Puis on remplace la ligne DEVICES="" ci dessus par la ligne :


DEVICES="/dev/serial0"


On vérifie ensuite que les données NMEA sont correctement lues et traitées en lançant l’utilitaire de visualisation graphique gpsmon :

pi@raspberrypi:~ $ gpsmon
 

Exploitez la famille Berry en toute simplicité

La mise en œuvre des magnétomètres, accéléromètres et autres gyroscopes est une sorte de rite de passage obligé pour le concepteur de systèmes embarqués, qui plus est une technique dont il ne regrette jamais la maîtrise. Les cartes du fabricant Ozzmaker présentent à cet égard deux atouts : elles sont idéales pour expérimenter avec ce genre de capteurs, et leur documentation éminemment pratique facilite leur usage.

Elles conviennent également la production de petites séries, puisqu’en petites quantités elles reviennent moins cher qu’une fabrication maison ou professionnelle. Oserai-je conclure en disant que je les trouve Berry good ?


Votre avis, s'il vous plaît ?

Veuillez adresser vos questions ou commentaires (en anglais) par courriel à tamhan@tamoggemon.com ou (en français) à redaction@elektor.fr.


Ont contribué à cet article
Auteur : Tam Hanna
Rédaction : Thomas Scherer
Maquette : Giel Dols
Traduction : Hervé Moreau