Création d’un robot autonome pour l’exploration et la mesure de surfaces

Récemment, notre département en Intelligence Artificielle a livré une preuve de concept d’un robot autonome utilisé pour explorer et cartographier des espaces industriels et résidentiels inconnus tout en identifiant les différents types de sols.

Le robot (à l’exception de son châssis Roomba) est entièrement construit à partir de composants matériels et logiciels open-source (OS). Le résultat est un mélange d’algorithmes génétiques et de réseaux de neurones qui permettent au robot de cartographier, d’étudier et de mesurer de façon autonome des espaces intérieurs / extérieurs non-triviaux.

Dans un cas d’utilisation industrielle, l’équipe a présenté une démonstration où le robot est utilisé par une entreprise de nettoyage fictive afin d’optimiser ses coûts. Le robot est alors placé dans un entrepôt fictif où il explore les surfaces après les heures de travail. Ensuite, il envoie un rapport détaillé à la société de nettoyage avec une carte des différentes zones, sections et types de sols. Ce rapport aide l’entreprise de nettoyage à facturer efficacement son client dans le cadre d’un contrat de maintenance régulier et à ainsi réduire le facteur humain d’une partie de son processus d’acquisition de clients, optimisant ainsi les coûts.

Le projet en est encore à ses débuts et nous sommes convaincus que de nombreux cas d’utilisations seront découverts tout au long du processus de développement  par exemple en ajoutant la possibilité d’explorer les espaces extérieurs.

Même si la nouveauté réside principalement dans la partie logicielle, notre équipe IA a baptisé leur robot, SMOB – abréviation de Self-Mapping Open Bot.

Création d'un robot autonome pour l'exploration et la mesure de surfaces, un projet R&D en Intelligence Artificielle
Le SMOB en action, surveillant et cartographiant les bureaux de Savoir-faire Linux

Comment fonctionne le SMOB ?

Le projet est un mélange unique de conception matérielle et logicielle. Comme le robot devait être résistant aux collisions avec des objets et devait pouvoir voyager à une vitesse raisonnable, utiliser l’ensemble du kit TurtleBot n’était pas une option dans de telles conditions. L’équipe a résolu le problème en associant la base Roomba Create (qui convient bien aux opérations lourdes) à l’IMU (Inertial Measurement Unit – Navigation inertielle), au LIDAR (LIght Detection And Ranging – Détection et estimation de la distance par la lumière) et au Raspberry Pi3 du kit TurtleBot 3 DIY. Afin d’atteindre les latences requises pour des opérations fluides, l’équipe a également modifié le noyau Debian pour prendre en charge le jeu d’instructions 64-bits disponible sur le processeur ARMv9 (les modifications étaient basées sur le projet PI64).

Les algorithmes de SMOB

SMOB combine deux techniques différentes pour atteindre ses objectifs : En premier lieu, l’algorithme de découverte spatiale est une implémentation de l’algorithme génétique proposé par Mohamed Amine Yakoubi et Mohamed Tayeb Larski. L’algorithme est réalisé en Python afin de pouvoir travailler avec le framework ROS, qui alimente les mouvements du robot.
La partie la plus complexe a été la réalisation du réseau neuronal convulsif, qui est responsable de la classification des types de sols. Le principal défi était d’identifier correctement les propriétés d’une image (netteté, luminosité, taille, position de la caméra, etc.) afin que le réseau soit le plus efficace possible – une recherche qui a nécessité de nombreux essais et erreurs.

Résultats de tests

Nos expériences montrent une performance de couverture d’environ 1m^2 par minute pour un robot à bas coût (environ 600 USD).

Qu’est-ce qui fait de SMOB un robot unique?

SMOB est unique, car il fait partie des premières expérimentations où un robot exécute plusieurs tâches complexes sur du matériel embarqué. On peut affirmer avec certitude que la conduite automatisée utilise déjà des algorithmes qui sont très en avance sur ce que SMOB peut faire, mais ils sont aussi beaucoup plus complexes que les solutions de base et à faible coût de traitement de SMOB. Le robot SMOB se base sur le minimalisme – il est question d’une tentative de créer des solutions simples à des problèmes qui sont actuellement résolus par beaucoup plus de puissance et par des algorithmes qui demandent beaucoup plus de mémoire.

L’avenir de SMOB dans le domaine de la robotique

L’un des plus grands défis en amont de ce projet comprend le traitement des opérations extérieures liées aux capteurs LIDAR et les problèmes qui y sont associés. LIDAR – un appareil qui cartographie des objets en 3-D en faisant rebondir les faisceaux laser hors de son environnement réel – est l’un des composants les plus cruciaux et les plus litigieux de tout véhicule (dans ce cas, le SMOB) qui est censé se conduire (Lire par exemple: Simonite, 2017). Le LIDAR de SMOB est incapable d’identifier le verre. Il a également des difficultés dans la détection de fermetures de boucles et à naviguer sur des surfaces complexes. Par exemple, un SMOB conçu pour détecter des nids de poule à l’extérieur aurait très probablement besoin d’un châssis et d’un système de propulsion différents, mais devrait être aussi capable de détecter les nids de poule avant de les atteindre; sinon, il ne sera peut-être pas capable d’en sortir une fois piégé à l’intérieur.

Références
Simonite, T. (2017, March 20). Self-Driving Cars’ Spinning-Laser Problem. MIT Technology Review.

Session IoT – plateformes embarquées au Paris Open Source Summit pilotée par l’équipe Savoir-faire Linux

iot

 

Le Paris Open Source Summit, 1er événement européen libre et open source, articulé autour trois thèmes (Technologie, Entreprise et Société), abordera cette année les perspectives industrielles et commerciales de l’Open Source mais aussi ses impacts technologiques et sociaux.

Savoir-faire Linux qui s’est activement impliqué dans l’organisation de cet événement en définissant notamment le programme de la thématique « Tech », sera également responsable de la session : IoT – Plateformes embarquées. C’est Jérôme Oufella de Savoir-faire Linux qui animera cette session, rythmée par les interventions d’experts du secteur.
jerome_photoJérôme est diplômé de l’École Supérieure d’Ingénieurs de Luminy (ÉSIL). Il est vice-président Technologies de Savoir-faire Linux qu’il a rejoint en 2004 et en définit aujourd’hui les grandes orientations technologiques. Il est également directeur du département « Ingénierie Produits » regroupant les domaines d’ingénierie logicielle, de pratique Linux industrielle et embarquée. Jérôme est engagé dans tous les grands projets liés au monde industriel et aéronautique et organise les pratiques de contributions aux logiciels libres de Savoir-faire Linux.

Présentation de la session

Cette session présentera l’approche du logiciel libre dans la conception et l’ingénierie de produits, tels que les objets connectés (industriels ou non), afin de s’inscrire dans une véritable stratégie IoT (Internet des Objets).

Les conférences aborderont l’ensemble des aspects Open Source ainsi que les choix technologiques disponibles, en se basant sur des retours d’expérience du marché.

Vue d’ensemble du programme

Mercredi 16 Novembre, de 13h30 à 15h30 à la Salle Venise

Horaire Titre Conférencier Organisation
13:30 – 14:00 Open-Design : L’impact de l’approche Open sur la conception de produits Étienne Boisseau École des Arts & Métiers – Paris Tech
Laboratoire Conception de Produits et Innovation
Doctorant
14:00 – 14:30 Open Source, IoT et protocoles Jérôme Molière Ucare
CEO
14:30 – 15:00 Open source comme accélérateur du développement de l’Industrie 4.0 –
Proposotion d’une solution open source pour l’IoT industriel.
Tuan Dang EDF R&D
Ingénieur Expert
15:00 – 15:30 IoT: Connect your analog business to a digital world Olivier Mikeladze Red Hat
Solution Architect Manager

13:30 – 14:00
Open-Design : L’impact de l’approche Open sur la conception de produits

  • Comment l’open s’est étendu au delà du monde du logiciel ? Que représente l’open-source hardware?
  • Quel est l’impact sur la conception de produits ?
  • Ce sera aussi l’occasion de faire le point sur les meilleures pratiques transférables ou non du soft au hardware.

Intervenant : Étienne Boisseau, Ecole des Arts & Métiers – ParisTech Laboratoire Conception de Produits et Innovation. Doctorant

Biographie : Ingénieur en génie mécanique et industriel, Étienne Boisseau effectue une thèse de doctorat dans le Laboratoire Conception de Produits et Innovation d’Arts & Métiers ParisTech. Ses recherches portent sur l’impact de l’Open Source sur le processus de conception de produits tangibles. En effet, si le passage de la « cathédrale » au « bazar » a été étudié dans le développement Logiciel, le passage des bits aux atomes reste récent et n’est pas si évident !


14:00 – 14:30
Open Source, IoT et protocoles

  • Quel protocole pour quel type d’application? Un panorama des solutions possibles.

Intervenant : Jérôme Molière, Ucare CEO

Biographie : Jérôme est diplômé de l’école d’Ingénieur ESIGELEC. Il est spécialiste Java depuis 1996 et passionné par Linux et Emacs depuis plus de 20 ans. Jérôme est auteur pour les éditions Eyrolles, pour divers magazines et sites Web. Il a été notamment conférencier aux RMLL OSGi World Gartner. Depuis 2014, il a fondé sa propre entreprise dont il est CEO.


14:30-15:00
Open source comme accélérateur du développement de l’Industrie 4.0

  • Le développement d’une solution Open Source pour la mise en œuvre de l’IoT dans le contexte des chantiers mobiles connectés en milieu industriel.
  • Les briques logicielles et l’architecture de la chaîne de valeur : objets connectés-middleware-applications métiers
  • Présentation de la « Task Force IoT industriel »

Intervenant : Tuan Dang, EDF R&D Ingénieur Expert

Biographie : Tuan DANG est diplômé de l’École Centrale de Nantes et docteur de l’École Nationale Supérieure des Télécommunications de Paris. Il exerce sa fonction d’ingénieur chercheur expert à EDF R&D. Ses activités portent sur les réseaux de communication industriels. Il participe actuellement aux développements de protocoles de communication industriels ouverts et open source destinés aux applications industrielles ayant un cycle de vie très long.


15:00 -15:30
IoT: Connect your analog business to a digital world

IoT is one of the hottest topics in our industry today and perhaps the biggest market opportunity across enterprises over the next several years. Although a lot of the media attention is on smart refrigerators or other aspects of consumer IoT, analysts expect much of the business opportunity to be in enterprise deployments of embedded gateway devices and data-related services. In this session, we will discuss what should be an IOT strategy.

Intervenant : Olivier Mikeladze, Red Hat Solution Architect Manager

Biographie : Olivier conduit une équipe d’architectes spécialisés sur les solutions émergentes Red Hat, notamment dans les domaines du Devops, des architectures micro services, des plateformes de gestion de conteneurs applicatifs, de l’IoT et du Cloud. Il est fort d’une expérience de 17 ans l’IT, en tant que développeur et architecte sur projets, consultant Spécialiste Middleware, architecte avant-vente au travers de son parcours professionnel chez Cap Gemini, BEA System, Oracle et Red Hat.

 

Un logiciel, deux villes, trois développeurs

Ring est un logiciel aussi mobile et dynamique que son équipe! Alors que la version beta sera prochainement annoncée (suivez bien l’actualité de Ring!), trois de nos développeurs se rendront les 19 et 20 mars à Boston et Singapour, pour deux événements majeurs dans l’univers du logiciel libre: Libre Planet et Fossasia.

Ring_logo

RingLes objectifs? Présenter Ring et ses valeurs, à travers sa technologie hors du commun, et collaborer avec des experts du monde entier sur ce logiciel de communication en temps réel. Deux rendez-vous pour mieux comprendre les fondements de Ring et voyager dans ce projet prometteur!

Prenez le contrôle et communiquez librement avec Ring

libre planet_logoSur le thème « changer le système » (Fork the system), Libre Planet accueille Savoir-faire linux pour une conférence qui mettra de l’avant les valeurs du projet Ring. Adrien Béraud et Guillaume Roguez – qui avait présenté le logiciel lors du FOSDEM – expliqueront plus particulièrement comment la technologie de Ring offre aux utilisateurs un outil de liberté.

Pour Guillaume Roguez, directeur du développement de Ring chez Savoir-faire Linux:

Alors que la surveillance des échanges est un enjeu d’actualité, Ring permet à chacun de prendre le contrôle de ses communications, car il est à la fois sécurisé, transparent et modulaire.

La sécurité. Parce que Ring fonctionne sans serveur central et s’appuie sur des méthodes d’encryption, la vie privée des utilisateurs et la confidentialité de leurs échanges sont respectées.

La transparence. Placé sous licence libre, le code de Ring peut être entièrement étudié, modifié et partagé. L’équipe fait régulièrement des présentations pour que chacun puisse mieux se l’approprier.

La modularité. Ring s’adapte à différents composants logiciels et à divers environnements, comme celui de l’Internet des objets. C’est ce thème qui sera d’ailleurs développé lors du Fossasia.

Embarquez dans la technologie de Ring avec les objets connectés!

FOSSASIA_LogoL’internet des objets sera à l’honneur du FOSSASIA 2016 où Ring donnera une conférence. Pour cet évenement, Alexandre Lision réserve quelques surprises aux développeurs de Singapour:

« Je prépare une démonstration avec des objets connectés à Ring. Avec l’aide de collègues, je vais proposer quelques exemples d’applications intéressantes et simples à reproduire. »

Ring permet de passer des appels vidéo, à deux ou en groupe, et de communiquer par message texte. Mais il offre bien plus encore!

Par le service de clavardage, un développeur de Savoir-faire Linux gère l’éclairage de son salon. Adrien Béraud allume ou éteint à distance une ou plusieurs lumières, en envoyant un simple message texte avec Ring. Le montage du dispositif a pris moins d’une heure et peut être adapté pour contrôler la porte d’un garage ou un chauffage. (Lisez l’article Comment Ring communique avec les appareils connectés pour en savoir plus.)

Ring est également capable de se connecter à un système embarqué relié à une caméra, un microphone ou même à un robot. Ces possibilités offrent toutes sortes de perspectives aux utilisateurs, comme aux entreprises. Bien plus qu’un logiciel de communication, Ring est un outil ouvert à différents usages qui respecte votre liberté.

Comment Ring communique avec les appareils connectés #IoT

light-bulb - IoTQuand vous sortez de chez vous, êtes-vous sûr que les lumières sont éteintes? Avec Ring, vous pouvez le vérifier en vidéo et régler votre éclairage simplement en envoyant un message texte. De quoi faire des économies d’énergie!

En moins d’une heure, Adrien Béraud, développeur chez Savoir-faire Linux, a monté un dispositif lui permettant de contrôler l’éclairage de son salon alors qu’il est au bureau. Il a configuré le compte Ring de son ordinateur domestique pour accepter automatiquement chaque appel et peut ainsi l’appeler pour voir en temps réel, en vidéo, son salon à distance. Il peut alors vérifier si les lumières sont allumées et, au besoin, les éteindre en utilisant le module de clavardage de Ring!

Un dispositif simple, monté avec du matériel libre

Arduino - IoTAdrien a d’abord relié les lampes de son salon à Internet, en utilisant un système connecté Particle Core (de type Arduino) et une carte d’extension relais (Relay Shield). Comme son éclairage est associé à un circuit va-et-vient, il peut facilement contrôler les lumières, même en cas de panne Internet ou en cas de problème avec le relais. Il a ensuite ajouté les quelques lignes de code fournies dans la documentation du relais pour connecter le dispositif à Internet.

Avec quelques lignes de commande, vos lampes sont connectées

Une fois la connexion établie, il a inséré une ligne de commande dans le terminal de son ordinateur Linux. Par exemple, pour éteindre (LOW) la première lampe (r1) :

curl https://api.particle.io/v1/devices/0123456789abcdef/relay -d access_token=123412341234 -d params=r1,LOW

Le contrôle des lumières par le clavardage de Ring peut ensuite se faire avec ce script Python :

#!/usr/bin/env python3
import re, json, http.client, urllib.parse
from controler import DRingCtrl

PARTICLE_API_TOKEN = '[your_api_token_here]'
PARTICLE_REQ_URI = '/v1/devices/[your_device_id_here]/relay'
PARTICLE_REQ_RE = re.compile('^(r[0-4],(?:HIGH|LOW))$')

class LightRingController(DRingCtrl):
    def __init__(self):
        super().__init__("LightController")

    def tryParticleReq(self, params):
        try:
            conn = http.client.HTTPSConnection('api.particle.io')
            p = urllib.parse.urlencode({'access_token': PARTICLE_API_TOKEN, 'params': params})
            conn.request("POST", PARTICLE_REQ_URI, p, {"Content-type": "application/x-www-form-urlencoded", "Accept": "text/plain"})
            ret = json.loads(conn.getresponse().read().decode())['return_value']
        finally:
            conn.close()
        return ret

    def onIncomingMessage(self, callid, ufrom, message):
        super().onIncomingMessage(callid, ufrom, message)
        msg = message['text/plain']
        res = re.search(PARTICLE_REQ_RE, msg)
        if res:
            op = res.group(0)
            print('Command:', op)
            ret = self.tryParticleReq(op)
            self.callmanager.sendTextMessage(callid, {'text/plain':'Got: '+str(ret)}, False)

if __name__ == "__main__":
    ctrl = LightRingController()
    ctrl.run()

L’Internet des objets: des possibilités infinies

De nombreux usages sont possibles, du plus simple au plus complexe. Par exemple, un appel Ring peut être directement associé à la mise en marche de votre éclairage, avec ce simple script :

#...

class LightRingController(DRingCtrl):

    #...

    def onCallStateChanged(self, callid, state, statecode):
        super().onCallStateChanged(callid, state, statecode)
        if state == "HUNGUP":
            self.tryParticleReq('r1,LOW')
        elif state == "CURRENT":
            self.tryParticleReq('r1,HIGH')

Imaginez alors ce que vous pourriez faire si votre logiciel Ring était relié à votre chauffage ou à la porte de votre garage… Les perspectives sont infinies!

Vous avez des idées à partager ? Laissez un commentaire!

Analyseur logique : visualiser la latence entre deux signaux numériques en temps réel avec sigrok et matplotlib

Salae Logic AnalyzerDans mon billet précédent, je décrivais comment manipuler avec Python les données extraites d’un analyseur logique Saleae afin de visualiser la latence entre deux signaux numériques et en déduire la gigue temporelle de l’un d’entre eux. En conclusion, j’émettais l’hypothèse que le SDK de Saleae pourrait nous permettre de récupérer des informations sur les signaux en temps réel et non plus par l’intermédiaire d’un fichier CSV exporté. Mais au final, c’est un logiciel libre plus générique qui nous a fourni la meilleure solution.

La solution de Saleae et son SDK

Saleae propose aux développeurs deux solutions :

  • une API (en bêta à l’heure actuelle) qui permet uniquement de contrôler leur logiciel de visualisation depuis une socket.
  • un SDK qui permet d’étendre leur logiciel et écrire son propre analyseur de protocole.

Nous aurions pu a priori nous intéresser au SDK et écrire un analyseur qui exporte à la volée la latence entre deux signaux définis, mais cette solution est dépendante du logiciel de Saleae et de son évolution, ce qui nous garantit une très faible pérennité. De plus, le logiciel de visualisation de Saleae n’a pas pour vocation d’être utilisé avec un autre analyseur logique que ceux qu’ils produisent. Nous cherchions donc une solution plus générique et permanente.

Sigrok: une suite logicielle open-source pour les analyseurs logiques

C’est lors d’une discussion entre collègues qu’Emeric Vigier m’a mit sur la piste d’un logiciel nommé Sigrok. Ayant pour objectif de fournir une solution libre et générique pour les analyseurs logiques, Sigrok est une suite logicielle permettant d’extraire les données collectées par divers types d’analyseurs et de les afficher, voire de les traiter, à l’aide de décodeurs de protocole.

Cette suite se compose de plusieurs sous-projets :

  • libsigrok : une librairie écrite en C qui standardise l’accès aux pilotes des différents analyseurs.
  • libsigrokdecode : une librairie écrite en C qui fournit une API pour le décodage de protocole. Les décodeurs sont écrits en Python (>= 3).
  • Sigrok-cli : une interface en ligne de commande pour manipuler Sigrok.
  • PulseView : une interface graphique en Qt pour manipuler Sigrok.
  • Fx2lafw : Sigrok fournit également une implémentation open source du firmware des puces Cypress FX2 qui est la puce utilisé entre autre par Saleae dans toutes les déclinaisons de ses analyseurs logiques hormis le Logic Pro 16. Ce firmware permet de programmer le FPGA pour qu’il fonctionne comme un simple analyseur logique matériel.

Sigrok : exemple d’utilisation

Un exemple de cette suite mise bout à bout sera plus parlant qu’un long discours. Nous allons donc utiliser PulseView pour capturer et visualiser les signaux d’un analyseur logique.

À l’ouverture PulseView dans sa version 0.2.0 ressemble à ceci :
[cliquez sur les images pour les agrandir]

pulseview01

Nous allons commencer une capture en laissant le périphérique de démonstration générer des signaux aléatoires :

pulseview02

Nous allons ensuite ajouter un décodeur assez simple qui calcule le rapport cyclique d’un signal numérique :

pulseview03

Chaque décodeur dispose de ses options. Dans notre cas nous allons simplement définir le canal sur lequel nous voulons appliquer le décodeur :

pulseview04

Le calcul du rapport cyclique est appliqué sur le canal et reporté directement dans l’interface de PulseView :

pulseview05

Sigrok : écriture d’un décodeur pour le calcul de la latence entre deux signaux numériques

Ce qui suit est basé sur la libsigrok et la libsigrokdecode dans leurs version 0.3.0.
Chaque décodeur de protocole est un module Python qui possède son propre sous-répertoire dans le répertoire de décodeurs libsigrokdecode.

Un décodeur se compose de deux fichiers :

  • __init__.py : Ce fichier est requis pour l’initialisation du décodeur et contient une simple description du protocole.
  • pd.py : Ce fichier contient des métadonnées sur le décodeur, et son code, la plupart du temps implémenté dans la méthode decode()

Nous allons nous intéresser au fichier pd.py contenant le code de notre décodeur. L’API de la libsigrokdecode nous fournit toutes les informations sur les signaux capturés.

Rappelons nous que pour calculer la latence entre deux signaux numériques, notre logique est de considérer l’un des signaux comme une horloge de référence, et l’autre comme une résultante de ce premier. Les deux étant liés, à chaque transition d’état du signal d’horloge, le signal résultant changera aussi d’état avec une latence plus ou moins variable. Nous parlerons de la fluctuation de cette latence plus loin.

Les options du décodeur

La première chose à faire est donc de permettre à notre décodeur de définir quel canal correspond au signal d’horloge et quel canal correspond au signal résultant. La classe du décodeur permet justement de définir quelques attributs précisant ses options, notamment celle permettant à l’utilisateur de choisir les canaux :

class Decoder(srd.Decoder):
   # ...
   channels = (
      {'id': 'clk', 'name': 'Clock', 'desc': 'Clock reference channel'},
      {'id': 'sig', 'name': 'Resulting signal', 'desc': 'Resulting signal controlled by the clock'},
   )
   ...

La méthode decode()

La seconde étape va être d’implémenter le contenu de la méthode decode(). Cette méthode est appelé par la libsigrokdecode chaque fois qu’un nouveau bloc de données à traiter est disponible.

Chaque bloc est en fait un échantillon dépendant de la fréquence d’échantillonnage de nos signaux. Par exemple pour une valeur d’échantillonnage de 100 Hz, nous obtiendrons 100 blocs de données par seconde. Ces blocs de données contiennent le numéro de l’échantillon actuel, ainsi que l’état des différents signaux à cet instant.

À partir de ces informations, il est ainsi très facile d’implémenter une machine à état qui va noter à quel échantillon à eu lieu la transition du signal d’horloge et celle du signal résultant. Le nombre d’échantillons écoulés entre les deux, multiplié par la valeur de la fréquence d’échantillonnage, va nous donner la latence exprimée en secondes.

Dans sa version simplifiée, notre machine à état ressemble à cela :

def decode(self, ss, es, data):

    self.oldpin, (clk, sig) = pins, pins

    # State machine:
    # For each sample we can move 2 steps forward in the state machine.
    while True:
        # Clock state has the lead.
        if self.state == 'CLK':
            if self.clk_start == self.samplenum:
                # Clock transition already treated.
                # We have done everything we can with this sample.
                break
            else:
                if self.clk_edge(self.oldclk, clk) is True:
                    # Clock edge found.
                    # We note the sample and move to the next state.
                    self.clk_start = self.samplenum
                    self.state = 'SIG'

        if self.state == 'SIG':
            if self.sig_start == self.samplenum:
                # Signal transition already treated.
                # We have done everything we can with this sample.
                break
            else:
                if self.sig_edge(self.oldsig, sig) is True:
                    # Signal edge found.
                    # We note the sample, calculate the latency
                    # and move to the next state.
                    self.sig_start = self.samplenum
                    self.state = 'CLK'
                    # Calculate and report the latency.
                    self.putx((self.sig_start - self.clk_start) / self.samplerate)

    # Save current CLK/SIG values for the next round.
    self.oldclk, self.oldsig = clk, sig

Les sorties de notre décodeur

La libsigrokdecode propose différentes façons de remonter les informations de notre décodeur. Une méthode register() permet d’enregistrer les sorties que notre décodeur génère. Chaque sortie a un type défini; par exemple, le type OUTPUT_ANN est utilisé pour définir une sortie de type annotation qui sera représentée dans PulseView par les boîtes graphiques que nous avons vues précédemment avec le décodeur de rapport cyclique.

Pour notre décodeur, nous voulons principalement deux types de sorties:

  • une sortie de type annotation (OUTPUT_ANN) pour visualiser la latence mise en forme dans PulseView,
  • et une sortie de type binaire (OUTPUT_BINARY) pour sortir les valeurs de latence brute sans mise en forme afin d’être analysé.

La version finale de notre décodeur inclut également une sortie de type métadonnée (OUTPUT_META) rapportant des statistiques sur les signaux manqués, mais ce n’est pas important ici.

Nos deux sorties donc sont définies dans notre décodeur comme suit :

self.out_ann = self.register(srd.OUTPUT_ANN)
self.out_bin = self.register(srd.OUTPUT_BINARY)

Pour reporter des informations sur ces sorties nous utilisons la méthode put() qui a pour prototype :

put(debut_echantillon, fin_echantillon, type_de_sortie, donnees)

type_de_sortie est une de nos deux méthodes enregistrées au préalable (out_ann, out_bin).

Pour reporter la latence entre deux signaux en utilisant le type annotation nous pourrons par exemple écrire :

put(clk_start, sig_start, out_ann, [0, [ma_latence]])

Les résultats obtenus avec notre décodeur de latence

Voici un exemple des résultats obtenus avec notre décodeur dans PulseView :
pulseview06

Et les résultats obtenus avec sigrok-cli dans sa version 0.5.0 et la sortie binaire pour avoir les valeurs de latence brute :
sigrok-cli

Visualisation des données en temps réel pour en déduire la gigue temporelle

Comme nous venons de le voir, sigrok-cli nous permet de sortir les valeurs de latence brute sur la console en temps réel. Nous allons maintenant nous intéresser aux variations de cette latence. En effet, rien ne nous garantit que la latence entre ces deux signaux sera constante.

Considérant que le signal d’horloge est périodique et sans fluctuation, en théorie, le signal résultant devrait l’être aussi et la latence entre ces deux signaux devraient être constante. Si ce n’est pas le cas, c’est qu’il y a une fluctuation de cette latence que nous avions décrite dans le précédent article comme la gigue temporelle d’un signal, et c’est ce que nous voulons visualiser maintenant.

Nous pouvons donc imaginer récupérer ces valeurs à la volée et les mettre en forme dans un graphique. Pour cela, nous allons encore une fois écrire un script en Python.

Je me suis intéressé à la librairie matplotlib et son module d’animation, qui propose une méthode FuncAnimation() permettant de définir une fonction à appeler pour mettre à jour le graphique à chaque fois que de nouvelles données sont disponibles. Cette fonction prend en paramètre la figure sur laquelle nous travaillons, la fonction d’animation à appeler et l’ensemble de données à traiter.

anim = animation.FuncAnimation(fig, animate, frames=data_gen)

Ces données peuvent être de la forme d’un générateur Python qui va très bien de paire avec la lecture d’un flux de données (merci à Guillaume Roguez pour m’avoir présenté ce type d’objet).

Ainsi à chaque fois qu’une nouvelle latence sera écrite dans le flux, notre générateur récupérera une nouvelle donnée et la fonction d’animation sera appelée.

Voici à quoi ressemble le code du générateur :

# The data generator take its
# input from file or stdin
def data_gen():
    while True:
        line = fd.readline().strip()
        if line:
            yield line

Notre fonction d’animation va, si besoin est, mettre à jour l’abscisse pour visualiser toutes les latences, et ajouter la nouvelle valeur fournie par le générateur.

# The update graph function
def animate(data):
    global x_max, x_min, x, y

    try:
        # we must recalculate the abscissa range
        x_new = float(data)
        if x_max is None or x_new > x_max:
            x_max = x_new
        if x_min is None or x_new < x_min:
            x_min = x_new
        ax.set_xlim(x_min, x_max)

        # add the new plot coordinate
        x.append(x_new)
        y.append(0)
        line.set_data(x, y)

        return line,

    except KeyboardInterrupt:
        print("leaving...")

Finalement, il nous reste plus qu’à éxécuter sigrok-cli avec notre décodeur de latence et à récupérer ces valeurs dans notre script de visualisation.

sigrok-cli -d fx2lafw --config samplerate=24MHz --samples 2M -C 1,2 -P jitter:clk=1:sig=2 -B jitter | rt-draw.py

Ce qui nous donne le résultat final suivant et qui nous permet de visualiser la gigue temporelle du signal résultant :

rt_draw