Transmission holonome : aller de côté sans tourner

Cela aide beaucoup et ce parcours en suppose une partie. La lecture des codeurs, la boucle de vitesse, le budget d'alimentation et le problème du glissement sont les mêmes savoir-faire qu'exige un robot à deux roues, seulement avec quatre fois tout. Ce qui est vraiment nouveau ici, c'est la cinématique — un robot différentiel a deux vitesses contrôlables et un holonome en a trois — et la question de repère qui l'accompagne. Si vous n'avez jamais construit de robot roulant, construisez d'abord un suiveur de ligne ou un éviteur d'obstacles ; vous passerez votre temps sur les idées nouvelles au lieu de la soudure.

À peu près le double, et l'augmentation se trouve aux endroits qu'on oublie. Quatre roues mecanum coûtent deux à quatre fois le prix de quatre roues simples. Il faut quatre moteurs au lieu de deux, donc quatre canaux de pont en H et quatre câbles de codeurs, et quatre moteurs représentent environ le double du budget courant. Le contrôleur doit généralement grandir aussi : quatre codeurs exigent quatre broches à interruptions et quatre canaux PWM sur des minuteurs séparés, ce qu'un Arduino Uno n'a pas, donc la plupart des montages finissent sur un Mega ou un ESP32. Prévoyez la montée en gamme du contrôleur dès le départ plutôt que de la découvrir après avoir percé le châssis.

On peut la piloter, et pour un robot conduit à la main sur un bon sol, c'est honnêtement suffisant. Ce qu'on ne peut pas faire, c'est aller quelque part de précis. La cinématique fonctionne en tenant des rapports entre quatre vitesses de roues, et la PWM en boucle ouverte ne tient pas de rapports — à mesure que la batterie s'affaisse, qu'un moteur chauffe, que la charge se déplace, les rapports dérivent et le robot sort de chaque commande en courbe. Sur un robot à entraînement différentiel, on corrige cela avec une constante d'ajustement. Sur une base holonome, le bon rapport change à chaque commande, donc il n'y a rien à ajuster. Les codeurs sont ce qui rend vraies les maths de ce parcours.

Parce que c'est l'échec qu'on ne voit pas venir. Une base mecanum ressemble au robot le plus capable que vous ayez construit, et son estime à l'aveugle est la pire. Le glissement des galets n'est pas un défaut à corriger — c'est ainsi qu'a lieu le mouvement latéral — donc chaque millimètre de déplacement latéral est un déplacement que le codeur a mesuré et que le sol n'a pas forcément accordé. Deux tutoriels de ce parcours existent pour que vous prévoyiez cela dès le départ : ajoutez une IMU pour le cap, ajoutez des roues libres non motrices ou une référence externe pour la position, et n'écrivez jamais une routine autonome qui suppose que les codeurs de propulsion savent où est le robot.

À un robot que vous pouvez conduire n'importe où sur un sol plat, qui tient les vitesses commandées, qui sait où il pointe, et qui est honnête sur le fait de ne pas savoir exactement où il est. Il omet délibérément trois choses. La transmission swerve, car huit moteurs et une singularité de direction sont un autre projet. La localisation absolue — SLAM, balises, vision — vers laquelle aller ensuite si le robot doit connaître sa position ; commencez par le parcours de planification de trajectoire et de cartographie. Et le suivi de trajectoire holonome, car la poursuite pure et Stanley supposent tous deux un robot qui dirige, et les adapter à une base qui peut aller de côté change assez le contrôleur pour mériter son propre traitement.

Le projet de robot omnidirectionnel mecanum de ce site est la cible directe : une base à quatre roues avec une boucle de vitesse par roue, une conduite orientée terrain, et une série de tests d'établi qui disent si chaque partie fonctionne vraiment. Au-delà, la même transmission sert de base à tout ce qui doit tenir un cap tout en se repositionnant — une plateforme caméra, un petit transporteur d'entrepôt, un robot d'inspection dans une allée étroite, ou un robot de compétition qui doit s'aligner sur quelque chose sans le pointer.