Intro

Dans cet article, je dresse un bilan de ma recherche de solution alternative à matlab/simulink pour la simulation d’algorithme de contrôle/régulation.

Commençons par une petite mise en contexte. Si vous n’avez aucune idée de ce qu’est l’automatique, je vous laisse aller lire l’article wikipédia. C’est un vaste domaine qui couvre notamment, l’asservissement et la régulation de systèmes.

Un exemple: le fait d’attraper un objet avec ses doigts peut-être représenté comme un montage en asservissement. Le capteur est l’oeil, l’actionneur le bras et le cerveau le centre de calcul. La méthode classique pour documenter ce type de fonctionnement est de le représenter sous la forme d’un schéma fonctionnel:

Ce type de schéma permet de mettre en évidence les boucles de rétro-action ainsi que les différents éléments composant le système et leur interface avec le monde extérieur.

Pour prendre un autre exemple, plus concret, on va s’intéresser à la régulation en vitesse d’un moteur DC. Il servira aussi de référence tout au long de cet article. Son schéma fonctionnel est le suivant:

La simulation en automatique

Commençons par définir nos attentes quant aux solutions de simulation. Pour ma part, j’ai deux critères principaux:

1. De bien simuler! Là c’est le rôle du solveur. Ce n’est pas vraiment mon domaine alors je ne rentre pas dans les détails
2. D’être lisible. Comme on l’a dit en introduction, en automatique beaucoup de choses sont représentées sous la forme de schéma fonctionnel. Donc il est nécessaire de pouvoir rapidement faire la correspondance entre le code et le schéma

On pourrait aussi citer la rapidité, l’observabilité ou encore la facilité d’itération/modification, mais tous ces points sont plus ou moins liés au solveur et son interface.

Pour effectuer une comparaison des différentes solutions, on va se baser sur notre exemple d’asservissement et régulation en vitesse d’un moteur DC. Un cas d’application concret pourrait être le pilotage du moteur de brosse d’un aspirateur sans fil.

On représente ce pilotage par le schéma suivant:

On définit la fonction de transfert du moteur dans le domaine de Laplace tel que:

$I(s) = \frac{U(s) - Ke\Omega_m}{Ls+R}$

Avec:

• I: le courant traversant le moteur (A)
• U: la tension aux bornes du moteur (V)
• Ke: la force électromotrice (V/rad/s)
• Ohmega: la vitesse de l’arbre du moteur (rpm)
• L: l’inductance du moteur (H)
• R: la résistance du moteur (Ohm)

$Cem = Kt \times I(s)$

Avec:

• Kt: la constante de couple (N.m/A)

$\frac{\Omega_m}{Cem - Cr}=\frac{1}{Js+Kf}$

Avec:

• Cem: le couple électromagnétique (N.m)
• J: le moment d’inertie (kg.m²)
• Kf: les frottements visqueux (N.m.s)

On en profite pour définir aussi la fonction de transfert du régulateur PID:

$PID=Kp+\frac{Ki}{s}+sKd$

Je ne rentre pas dans les détails de ces fonctions de transferts, ni même sur ce qu’est une fonction de transfert. Dans notre cas, on peut la considérer comme le modèle virtuel de notre moteur. En les intégrant au schéma fonctionnel précédent on obtient le schéma suivant:

Maintenant que nous avons défini notre exemple, nous allons implémenter ce système avec différents outils et en comparer l’utilisation. Vu que le logiciel MATLAB/simulink est la référence dans le domaine, on va commencer par lui.

Matlab/simulink

Commençons par quelques définitions.

• MATLAB c’est le nom d’un langage de script, mais aussi celui de son environnement de développement. MATLAB a été conçu pour manipuler des matrices et afficher des courbes
• Simulink est un logiciel de modélisation de système dynamique reposant sur MATLAB. Il permet de créer des programmes sous la forme de schéma/blocs

Pour schématiser grossièrement, MATLAB est le moteur et simulink l’interface utilisateur.

Maintenant que les présentations sont faites, passons à la mise en place de notre exemple. MATLAB n’étant pas un logiciel libre, une licence est requise pour son utilisation. Heureusement pour moi, l’éditeur propose une offre découverte gratuite à utiliser via une interface web (utilisation limitée à 20h/mois). Donc on ouvre MATLAB, on lance simulink et on rentre l’équivalent schéma fonctionnel précédent, ce qui nous donne:

L’annotation en rouge est un ajout de ma part. Mais on remarque tout de suite l’un des points forts de simulink, son interface permet de faire un programme ayant une mise en forme proche du diagramme fonctionnel.

Un exemple de résultat de simulation, en jaune la consigne de vitesse et en bleu la vitesse du moteur. On peut visualiser ces valeurs grâce à la sonde nommée “Visualisation” sur notre schéma.

Scilab/xcos

Lorsque l’on cherche une alternative open source à MATLAB/simulink Scilab est LA solution évidente. En effet, ces deux solutions ont une interface utilisateur très proche ainsi qu’un langage de script assez similaire. Puisqu’une image vaut mille mots l’implémentation de notre exemple via scilab/xcos sera sans doute plus parlant:

La ressemblance avec simulink est frappante même si à l’utilisation les deux interfaces ne sont pas strictement identiques. Un avantage qu’offre xcos, est d’intégrer la gestion du contexte (les variables comme Ke, L ou R) directement dans le fichier de schéma-blocs. Pas besoin de créer de workspace comme sous MATLAB.

Cette solution est donc parfaitement viable. Cependant, xcos souffre d’un bug particulièrement pénible: l’instabilité des liaisons entre les blocs. Il n’est pas rare de rouvrir un projet de découvrir qu’une ou plusieurs liaisons ne suivent plus le routage original mais ont été remplacés par une liaison directe entre les points d’encrage. Ceci rend le schéma nettement moins lisible, nous obligeant à refaire les liaisons lorsque ça arrive…

Une autre limite de cette solution, par rapport à MATLAB, est la petitesse de sa bibliothèque de blocs comparée aux bibliothèques disponibles sur simulink. Mais tous ces défauts ne sont pas immuables et seront sans doute corrigés à l’avenir.

Python/Jupyter

Avec cet outil, je vous propose une autre approche, plutôt que d’écrire un programme par schéma-bloque afin qu’il ressemble au schéma fonctionnel de la documentation, nous allons intégrer le code dans la documentation. Ou la documentation dans le code c’est vous qui voyez!

Cette alternative repose sur un ensemble de logiciels dont les principaux sont:

• pyton le langage de programmation
• Jupyter l’interface graphique
• control, numpy et mathplotlib les bibliothèques scientifiques permettant de résoudre les équations, manipuler et afficher les données

Présentation

Comme je le disais en introduction, le principe de cette solution est de mélanger documentation et code. Pour être honnête, c’est le principe même de Jupyter, mais on va voir comment l’appliquer dans notre cas. On va donc enchaîner les parties documentations au format markdown et le code en python (on peut d’ailleurs utiliser d’autres langages, mais je n’ai pas étudié cette possibilité).

Dans cet exemple, on commence par un petit texte permettant de contextualiser le projet (1). On enchaîne ensuite avec l’importation des bibliothèques python nécessaires au projet (2). S’ensuit des explications plus précises quant au projet et le schéma fonctionnel permettant de le représenter (3). Enfin on termine la mise en contexte par la définition des différentes variables (4).

Modélisation du moteur DC

Cette approche a un gros inconvénient, elle est bien moins intuitive que la programmation par blocs. Cependant, elle offre d’autres avantages, comme une plus grande évolutivité et une plus grande souplesse dans la conception. Elle permet aussi de tester/valider des sous-ensembles sans devoir refaire le programme.

Par exemple, plutôt que d’écrire le code pour l’ensemble de la simulation, on peut commencer par faire super-bloc moteur qui inclut ses différents composants:

On remarque tout de suite que la courbe d’apprentissage de la bibliothèque control est plus raide que celle de simulink ou xcos. En particulier lorsqu’il s’agit de connecter les blocs entre eux (fonction ct.interconnect(...)).

Mais une fois cette difficulté surmontée, nous disposons maintenant un composant moteur ayant pour entrées U et Cr et pour sortie vitesse et que nous pouvons réutiliser à notre guise.

On peut donc facilement valider le comportement du moteur en boucle ouverte lorsqu’on le soumet à un échelon de tension de 10V:

Pour faire cet essai dans simulink ou xcos nous aurions dû créer un nouveau projet et y intégrer les blocs moteur, la commande de tension et une sonde de mesure et ensuite alterner entre les projets en fonction des modifications/validations à réaliser.

Cette modularité est donc très appréciable. Pour aller plus loin, on pourrait créer un fichier python séparé dans lequel on placerait notre composant moteur. Ainsi nous pourrions facilement le réutiliser dans différents projets.

Modélisation du régulateur

On peut maintenant passer au bloc du régulateur PID, enfin dans notre cas c’est seulement un PI, le terme dérivé étant nul.

Simulation complète

Nous avons maintenant tous les sous-ensembles nécessaires à la simulation de la régulation en vitesse du moteur DC. On commence donc par faire un rappel du système avec un schéma fonctionnel sans détails (1). Puis, on passe à la connexion des blocs et des entrées/sorties en python (2).

Enfin on peut afficher la réponse à un échelon de notre système. Dans notre exemple nous allons observer le comportement du moteur+asservissement pour une commande de vitesse de 1000 tr/min avec un couple résistant à zéro. Notre simulation durera une seconde avec un pas de temps 100 µs.

Ce projet dans son intégralité est disponible sur codeberg.

Bilan

Après avoir testé trois solutions différentes pour faire de l’automatique, quel est le bilan ?

Solution	Avantages	inconvénients
MATLAB/Simulink	Standard de l’industrie Programmation graphique proche du schéma fonctionnel Large bibliothèque de composants Nombreux exemples disponibles	Non open source Nouveau langage à apprendre (MATLAB) format fichier peu adapté au versionnage (simulink)
Scilab/Xcos	Open Source Programmation graphique proche du schéma fonctionnel	Nouveau langage à apprendre versionnage Bugs sur les liens (xcos) pénibles
Jupyter/control	langage python Modularité, on peut facilement faire ses bibliothèques de composants Open source simple fichier texte, facile à versionner	Courbe d’apprentissage plus raide Moins visuel, relecture plus difficile Communauté plus petite, donc moins de ressources

Avec cet article, je souhaitais partager mon expérience sur la recherche d’une solution open source pour l’automatique. Il y a évidemment l’incontournable Scilab/Xcos mais pas seulement. Pour les personnes qui, comme moi, sont plus à l’aise avec du texte qu’avec une interface graphique, d’autres solutions existent. Ici par exemple, on arrive en combinant l’éditeur Jupyter et quelques bibliothèques python, à avoir une solution offrant documentation et calculs.

Cette solution n’est pas sans inconvénients, notamment l’intégration de matplotlib dans jupyter qui n’est pas trivial… Mais elle offre aussi de nombreux avantages. Comme la facilité de créer des bibliothèques de composants, versionner efficacement le code et la documentation …

Pour ce qui est du versionnage, le code des bibliothèques est en python, la question ne se pose même pas et la partie notebook quant à elle est un fichier JSON, donc du texte. Cette solution vous permettra donc de gérer finement le versionnage de vos projets.

Autres pistes

Il existe encore d’autres solutions aux trois que j’ai étudiées ici, j’en ai trouvé une qui me convient alors je ne me suis pas attardé dessus mais si vous êtes intéressé voici une liste de celle que j’ai trouvées:

• OpenModelica
• octave
• Julia

Il existe certainement encore d’autres solutions que je ne connais pas…