Voir la source de Modules techniques/Carte de commande de moteurs

=[WIP]=

=Contexte du module technique=
Chaque année, nous concevons des solutions mécaniques permettant de marquer des points. Puisque le thème change, les actionneurs sont refaits à chaque fois. Cependant une chose ne change pas: c'est l'utilisation de moteurs. Que cela soit des moteurs à courant direct, des moteurs pas à pas ou des servo-moteurs, afin d'animer une articulation, déplacer un chariot sur un axe ou propulser un objet, ils sont indispensables. (Nous rédigeons une petite page expliquant la difference entre les types de moteurs).

Il n'est pas possible de piloter les moteurs directement via un microcontrôleur STM32 car le courant demandé est, la plus part du temps, largement supérieur à ce que la puce peut fournir. Si le courant tiré dépasse la limitation indiquée dans la datasheet, en générale 25mA par pin, de la fumée magique fera son apparition! Il reste possible d'alimenter des petits moteurs, mais c'est fortement déconseillé car dans le cas où la rotation est bloquée, le courant augmente et peut dépasser la valeur limite. Il est également possible qu'un courant de retour vienne griller la puce. C'EST DONC POUR CELA, qu'il faut utiliser un contrôleur moteur. Son rôle est de répartir l'alimentation en adéquation avec une commande. Dans notre cas, la commande vient du microcontrôleur, mais il n'est pas exclu que le signal soit généré par un circuit logique ou analogique. (Sur la même page en rédaction seront détaillées les façons de piloter divers moteurs).

Actuellement, nous faisons appel à des contrôleurs tout prêts et génériques, tel que le double pont H L298N ou le stepper driver DRV8825. Lors de l'assemblage de tous les composants mécaniques, nous nous sommes rendu compte que ces cartes prennent beaucoup de place. De plus, il arrive que ces cartes ne soient pas dotées de circuit de protection ou de limiteur de courant, ce qui donne lieu à, vous l'avez deviné, la fumée magique. Ajouté à cela, un temps fou passe dans le câblage qui n'est pas toujours très fiable. Et le dernier problème vient du nombre de GPIO sur notre carte Nucleo. Cette carte est utilisée pour piloter l'intégralité des modules sur le robot, et nous nous sommes heurtés à la limite de nombre de pins sur ce microcontrôleur.

Suite à tous ces problèmes que avons compris, qu'il serait pertinent d'avoir un PCB s'occupant exclusivement des moteurs des actionneurs. Cela devrait réduire la place occupée par les cartes, fiabiliser la connectique, alléger le microcontrôleur principal et diminuer le temps d'installation.

[insert image of controlers and moteurs and the stm32 :)]
=Cahier des charges=

L'idée serait d'avoir une carte embarquant l'intégralité des composants de puissances servant à piloter les moteurs. La commande serait générée par un microcontrôleur STM32 embarquer. Celui-ci recevrait des instructions générées par le microcontrôleur principale, pour le moment, notre carte Nucleo. Elles seraient transmises par un bus de données. La conception d'une telle carte laisse la liberté sur le choix de la connectique.

==Protocole de communication==
Les instructions reçues devront circuler sur un bus de données. Il existe plusieurs types de bus, tel que I2C, SPI, CAN, liaison série etc. Il est primordiale de bien réfléchir au type de communication que nous allons choisir, car il sera partagé parmi d'autres futurs modules. (Nous rédigeons une page sur la comparaison de ces protocoles de communication qui nous aidera à nous décider.)

Dans le milieu de la robotique, il est commun de rencontrer le système ROS. Il permet de coordonner différents modules de manière simple et efficace. (Une page explicative est en cours de rédaction. [https://www.ros.org Le site] de ce système opérationnel détail bien le mode de fonctionnement et les avantages. Sur notre page, nous contextualisons l’intérêt à nous tourner vers ROS). Un des points qui influencera notre choix de bus sera la compatibilité avec le système ROS.

==Composants de puissance==
(s'inspirer des contrôleurs existants, utiliser des outils comme la recherche de composants sur le site de farnell rs ou l'appli PartSeeker)

==Alimentation==
(convertisseur dc dc intégré, avoir un switch sur chaque contrôleur permettant de choisir la tension souhaitée

==Protection==
(court circuits, limitation de courant, diode de roulage, fusible, niveau de la programmation arrêt d'urgence)

==Connectique==
(xt60 et jst)

==Modularité==
(à voir, pourquoi pas faciliter le remplacement des composants de puissances, en théorie si la protection est bien faite on en aura pas besoin)