Suivant l'avis de nadar breicq dans le sujet viewtopic.php?f=103&t=18544&start=75
Ouvrons une nouvelle discussion sur les moteurs pas à pas et l'usage pour la coupe. Libre à vous d'ouvrir d'autres sujets pour les autres hors sujets tel que l'odométrie.
Donc, pour avoir utiliser du moteur à courant continu (MCC) et du moteur pas à pas (PAP) pour la propulsion, j'avoue que le pas à pas c'est plutôt génial quand on est pas bon en mécanique.
Le contrôle du mouvement d'un robot avec des MCC est performant, mais la vitesse du rotation est dépendante du couple résistant pour une tension donnée, donc si on veux un minimum aller droit cela implique généralement un asservissement. Donc qui dis asservissement, dis ajout de capteurs, qui peuvent être :
* une mesure de courant pour compenser une partie du couple résistant : intéressant, mais moyen pour controller la vitesse
* un capteur sur le moteur : facile mécaniquement, mais ne prends pas en compte les jeux de motoréducteur et les glissements des roues
* roues codeuses folles : plus compliqué mécaniquement et encombrant, mais donne une bien meilleure précision (autour de 1 cm au bout d'un match si c'est bien réglé)
* capteurs extérieurs (balises, lidar, télémètres, caméra) : pas de dérive, mais précision/rapidité en général plus faible que les roues codeuses
De l'autre côté, dans les moyens de propulsions habituels, nous avons les moteurs pas à pas. Ici, la vitesse de rotation ne dépends pas du couple résistant, tant que l'on reste dans sa capacité (c'est la partie importante!), donc le moteur fait exactement ce qui lui a été commandé, pas de dérive !
Les problèmes pouvant être rencontrés sont ce qu'on appelle les "sauts de pas", c'est à dire que l'on a fait avancer les commutations des bobines moteurs plus vite que la mécanique n'a pu les suivre, et on se retrouve avec un décalage et quelques pas perdus voir un blocage sur place du moteur (il ne fait que vibrer d'avant en arrière sur un même pas). Pour ne pas avoir ce problème, il faut se limiter à ne commander électriquement que ce que la physique permet : mettre des rampes d'accélération (car le couple fournit par le moteur est limité, donc l’accélération aussi) et faire attention aux vitesses maxi. Le bon point est que les moteurs Pas à Pas ne coûtent pas cher et sont facile à trouver de puissance suffisante pour faire faire 50 à 80cm/s à un robot de quelques kilogrames avec une rampe d'une seconde. La preuve que bien utilisé, un moteur PAP est fiable est précis, c'est que presque toutes les imprimantes 3D et fraiseuses les utilisent pendant des heures sans avoir le moindre capteur de position.
Il reste cependant une grosse source d'incertitude sur la position qui est le glissement des roues, le PAP ne garantissant que la vitesse de rotation du moteur. Mais c'est la même chose qu'avec des MCC. Les roues codeuses folles sont un bon ajout tout comme les capteurs extérieurs pour ne pas avoir de soucis après quelques déplacements. Une mécanique propre et équilibrée aide aussi.
Pour le côté pilotage électronique, il a été dis que cela été compliqué. Je ne suis pas entièrement d'accord, le fait de ne pas avoir besoin d'asservissement retire une partie de difficulté de programmation et réglage, il y a moins de capteurs donc moins d'électronique, mais le pilotage des pas rajoute une difficulté selon la solution choisie. En voici quelques unes :
* Faire les micro-pas en pilotant le courant de chaque bobine à la main : a déconseiller
C'est ce qu'on avait il y a un bon moment, car les composants tous fait étaient pas encore répandus !* Envoyer des impulsions depuis le MCU avec un logiciel maison à un driver traitant les micro-pas : très bien et facile pour le côté électronique. Reste une charge logiciel pas négligeable si on veut des rampes exactes. En faisant des choses approchées (palliers par exemple) cela devient plus simple. Un MCU avec un timer pour générer ces impulsions (mode PWM, mais en changeant la fréquence et non le rapport cyclique) simplifie fortement la vie et la charge du processeur, et est disponible dans tous les MCU que je connais ou presque.
* Utiliser une bibliothèque logicielle de gestion des pas à pas associé à un driver traitant les micro-pas : le logiciel de beaucoup d'imprimantes 3D est open source, et il est possible de l'utiliser pour la partie gestion des pas et des rampes et mettre le code du robot au dessus. Voir grbl par exemple (http://www.aquickcnc.com/wiki/Grbl). Pas de besoins matériels particulier, c'est fait pour Arduino !
* Utiliser une carte de pilotage d'imprimante 3D et de la piloter en Gcode par UART depuis un MCU : rien à faire pour piloter les PAP, tout est déjà dedans. Il suffit d'envoyer des commandes du genre "G0 X1000 Y1000 F100" pour avancer droit sur 1 mètre à 100mm/s ! Les cartes de pilotage du genre le shield arduino RAMPS (https://reprap.org/wiki/RAMPS/fr) sont disponible, ainsi que des cartes tout intégrées (https://reprap.org/wiki/RAMPS/fr)
* Ne pas avoir de MCU du tout, et juste mettre la liste d'instructions Gcode dans une carte SD dans une carte tout intégrée de pilotage d'imprimante 3D : ça ca me ferais bien rire à essayer, mais pas d'IA possible
* Utiliser un driver gérant les rampes, pas exemple les L6470 de ST qui sont piloté par un bus SPI et prennent des ordres de position avec profil d'acceleration, et gèrent tout, y compris la détection de perte de pas sans capteur !
Bref, des avantages et inconvénients existent pour les 2 solutions MCC et PAP, mais des solution relativement simples à mettre en œuvre existent pour les 2.
Le gros avantage du PAP, c'est d'éliminer le besoin d'asservissement pour avoir un robot qui va relativement droit, sans ondulations sur le chemin comme on le vois souvent avec MCC, et sans nécessiter de capteurs particuliers.
Le MCC reste une bonne solution qui a aussi fait ses preuves parmi les meilleurs de la coupe, mais ce niveau de précision n'est pas atteinte comme ça d'un coup de baguette magique.
Le sujet est ouvert, à vous d'ajouter vos expériences, problèmes rencontrés, solutions trouvées, corrections de mes erreurs, .... lâchez vous !
).
