86 lines
4.7 KiB
TeX
86 lines
4.7 KiB
TeX
\documentclass{article}
|
|
|
|
\usepackage[T1]{fontenc}
|
|
\usepackage[french]{babel}
|
|
|
|
\title{Contrôleur de petite machine à bois}
|
|
\author{Matthieu Boyer, Sélène Corbineau}
|
|
|
|
\begin{document}
|
|
\maketitle
|
|
|
|
\section{Positionnement}
|
|
Nous nous sommes intéressés au contrôle de la petite machine à bois d'hackens
|
|
(une fraiseuse à commande numérique). Pour simplifier le problème et rendre
|
|
les échecs moins dangereux, nous l'avons considérée comme un \emph{plotter} :
|
|
la tête de la PMB tient un stylo et l'on trace une image. La monture du
|
|
stylo sur la tête est munie d'un ressort. De cette manière, la hauteur exacte
|
|
de la tête importe peu pour obtenir un trait correct. L'asservissement porte
|
|
alors principalement sur les axes X et Y.
|
|
|
|
Le format naturel de dessin ici est un format vectoriel comme le SVG. Comme
|
|
représentation intermédiaire, nous avons choisi le format de commande traditionnel
|
|
des machines à commande numérique, le GCode. Le GCode est une suite d'instruction
|
|
précisant des déplacements (linéaires, circulaires voire selon des courbes
|
|
de Bézier) et, pour chaque déplacement, une vitesse cible. Le choix des vitesses
|
|
cible et la manière de les réaliser à été au coeur du projet.
|
|
|
|
\section{Réalisation}
|
|
Dans le rendu fourni, le contrôleur n'est capable d'intéragir qu'avec le
|
|
simulateur. Pour ce faire, on lance le simulateur physique \verb|simulator.py|
|
|
puis le contrôleur \verb|main.py|. Afin de générer le GCode exécuté par
|
|
le contrôleur, on peut utiliser l'exécutable \verb|svgtroppagcode.py|.
|
|
|
|
Ce dernier exécutable est séparé, car, utilisant la bibliothèque \verb|toppra|,
|
|
il faut une version compatible de NumPy d'au plus 1.21.6, qui implique une
|
|
version de Python antérieure à 3.6. Pour avoir un environnement adéquat,
|
|
nous avons utilisé les machines des salles informatiques, qui ne sont pas
|
|
à jour. N'hésitez pas à revenir vers nous si vous rencontrez des difficultés.
|
|
|
|
\subsection{Contrôle de l'entrée}
|
|
L'entrée SVG est convertie en GCode. Pour ce faire, deux méthodes sont proposées:
|
|
\begin{itemize}
|
|
\item Un convertisseur naïf convertit fidèlement un SVG en GCode, les feedrates
|
|
étant choisis arbitrairement.
|
|
\item Un convertisseur utilisant \verb|toppra| : on convertit le SVG en chemins,
|
|
puis on rééchantillone ce chemin en prenant en compte les contraintes en
|
|
vitesse et accélération. Cette méthode à l'inconvénient de transformer les
|
|
courbes en lignes brisées au niveau du GCode (et non plus au niveau du contrôleur).
|
|
\end{itemize}
|
|
Le choix de la méthode dépend de l'objectif: si l'on ne souhaite pas nécessairement
|
|
un résultat extrêmement précis parce qu'on fabrique un pochoir par exemple, on
|
|
préfèrera le convertisseur utilisant \verb|toppra| car celui-ci soulage les moteurs.
|
|
Dans le cas contraire, le convertisseur naïf fournira un résultat plus précis,
|
|
puisque les erreurs ne s'additionnent pas à l'échantillonnage et à la réalisation.
|
|
|
|
\section{Fonctionnement}
|
|
La conversion depuis \verb|svg| se fait simplement en séparant les vecteurs du
|
|
fichier en chemins continus puis en convertissant vecteur à vecteur vers le GCode,
|
|
qui reprend des fonctions avec des sémantiques très similaires.
|
|
|
|
Nous nous sommes concentrés sur l'architecture de contrôle. Une classe
|
|
\verb|GCodeToMotors| supervise le processus de dessin, prenant en entrée du
|
|
GCode. Ce GCode est parsé, puis une boucle de contrôle est instanciée avec
|
|
le \verb|Controller| et le \verb|Hardware|. Le contrôleur décide de la commande
|
|
à appliquer étant donné la cible et l'état de la machine. L'instance
|
|
de \verb|Hardware| elle, expose deux fonctions, pour appliquer une commande et
|
|
examiner l'état de la machine.
|
|
|
|
Cette architecture modulaire permet au \verb|Hardware| d'implémenter des
|
|
interfaces diverses (commande directe du matériel, communication réseau, etc.).
|
|
Ici toutefois, on s'est restreint à une communication par socket à un processus
|
|
externe de simulation. Il est également facile de choisir la politique de contrôle
|
|
en implémentant des \verb|Controller| différents. Nous avons implémenté un
|
|
contrôleur naïf d'ordre 0, qui commande la machine à la vitesse spécifiée par
|
|
le GCode (constante par morceaux donc) et dans la direction nécessaire pour
|
|
atteindre le prochain point de contrôle. Nous avons tenté d'implémenter un
|
|
contrôleur PID, mais nous n'avons pas trouvé de coefficients donnant une
|
|
réponse intéressante : en pratique, les moteurs de la fraiseuse numérique
|
|
sont suffisamment puissants pour qu'aux vitesses raisonnables ne déchirant pas
|
|
le papier, l'inertie soit de fait négligeable.
|
|
|
|
Le simulateur fourni dans le rapport simule en temps réel, les pas de calcul
|
|
étant choisis les plus petits possibles. La communication asynchrone par socket
|
|
UNIX permet de mettre cela en oeuvre facilement.
|
|
|
|
\end{document}
|