Commande du bras robotique .V1

Cliquer pour masquer

Introduction

Les bras robotisés occupent une fonction particulière dans l’atelier de la Batcave du projet BATLab112. Ils ne constituent pas uniquement des éléments décoratifs destinés à renforcer l’esthétique industrielle du diorama : ils doivent être capables de réaliser des mouvements réels et de répondre à des commandes définies par le système de contrôle du diorama.

Avant leur intégration définitive dans l’atelier, une première étape consiste donc à développer et à tester leur électronique de commande. Cette première version, développée autour d’une carte Arduino Due, a pour objectif de valider les principes fondamentaux de commande des servomoteurs et d’explorer plusieurs modes de fonctionnement : commande manuelle, fonctionnement automatique et apprentissage de positions.

Cahier des charges

Objectif général

L’objectif de cette première version est de réaliser une maquette électronique capable de commander les bras robotisés équipant l’atelier de la Batcave. Le système doit permettre de piloter les différents axes des bras et d’expérimenter plusieurs modes de fonctionnement.

Trois modes de fonctionnement des bras robotiques sont retenus :

  • Un mode manuel permettant de commander directement la position des bras robotisés à l’aide des commandes de la console de commande.
  • Un mode automatique permettant d’exécuter une série de mouvements préalablement enregistrés, sans intervention humaine.
  • Un mode apprentissage permettant d’enregistrer successivement plusieurs positions afin de définir une séquence de mouvements qui pourra ensuite être reproduite automatiquement.

Au-delà de la réalisation du système lui-même, cette expérimentation présente également un intérêt pédagogique. Elle permet d’aborder concrètement les principes de commande d’un servomoteur, de positionnement angulaire et de programmation d’une séquence de mouvements. L’objectif n’est donc pas encore de reproduire le fonctionnement d’un robot industriel réel, mais de construire une première architecture fonctionnelle permettant de valider les choix techniques.

Spécifications fonctionnelles

Le mode manuel

Le mode manuel constitue le point de départ du système. Chaque articulation est commandée individuellement à partir d’un potentiomètre rotatif. La position du potentiomètre est convertie par la carte Arduino en consigne de position pour le servomoteur correspondant.

Le principe est volontairement simple :

action sur le potentiomètre → lecture de la position → génération du signal de commande → déplacement du servomoteur.

Cette commande en temps réel permet de vérifier individuellement le comportement de chaque articulation. Pour les deux bras robotisés, huit servomoteurs sont donc nécessaires au total, soit quatre servomoteurs par bras.

Mode automatique

Le mode automatique permet de reproduire une succession de positions préalablement définies dans le programme de l’Arduino. Contrairement au mode manuel, l’opérateur n’agit plus directement sur les articulations. La carte de commande exécute une séquence programmée. Ce fonctionnement permet notamment de tester la capacité du système à reproduire une trajectoire prédéterminée.

Dans cette première version, les positions sont directement intégrées au programme Arduino. Cette solution est suffisante pour valider le principe, mais elle montre rapidement ses limites dès lors que le nombre de mouvements augmente. La modification d’une séquence nécessite en effet de modifier le programme puis de reprogrammer la carte.

Mode apprentissage

Le mode apprentissage constitue une première tentative pour rapprocher le fonctionnement du système de celui d’un robot programmable. L’opérateur utilise les commandes du mode manuel pour positionner les différentes articulations. Une position peut alors être mémorisée. Plusieurs positions successives peuvent ainsi constituer une séquence. Une fois l’apprentissage terminé, la séquence enregistrée peut être restituée en mode automatique.

Le principe peut être résumé de la manière suivante :

positionnement manuel → mémorisation → positionnement suivant → mémorisation → restitution automatique.

Cette fonction constitue une étape importante dans l’expérimentation, car elle introduit la notion de trajectoire programmée sans nécessiter la définition préalable de chaque position dans le code source.

Spécifications techniques

Les actionneurs

Chaque bras robotisé dispose de quatre degrés de liberté. Chaque articulation est équipée d’un servomoteur assurant directement son positionnement angulaire.

Le choix du servomoteur présente plusieurs avantages pour cette première expérimentation :

  • alimentation en courant continu ;
  • commande relativement simple ;
  • positionnement angulaire intégré ;
  • maintien de la position ;
  • encombrement réduit ;
  • compatibilité avec une commande Arduino.

Ce choix permet ainsi de disposer rapidement d’une chaîne complète de commande :

Arduino → signal de commande → servomoteur → articulation.

Il ne s’agit cependant pas encore d’une solution représentative de la motorisation d’un véritable robot industriel. Le projet doit par la suite tenir compte de cette différence technologique. Les essais mécaniques permettront notamment de vérifier si le couple disponible est suffisant pour les différentes articulations.

L’unité de contrôle, une carte Arduino Due

La première unité de contrôle repose sur une Arduino Due. Cette carte constitue le cœur du système électronique. Elle assure simultanément :

  • la lecture des potentiomètres ;
  • la lecture des boutons poussoirs ;
  • la gestion des voyants d’état ;
  • la génération des signaux de commande des servomoteurs ;
  • la gestion des séquences automatiques ;
  • la mémorisation des positions en mode apprentissage.

Le choix de l’Arduino Due résulte avant tout d’une opportunité : une carte ayant été donnée pour le projet BATLab112, elle a naturellement été réutilisée pour développer cette première version du système de commande des bras robotisés.

Réalisation de la maquette électronique

La première version est volontairement réalisée sous la forme d’une maquette de prototypage sur breadboard. Cette approche permet de modifier facilement le câblage et de tester différentes configurations avant de concevoir une électronique plus définitive.

Listes du matériel

À propos des marques et sources d’approvisionnement.
Les marques, fabricants et sites marchands mentionnés dans cet article le sont uniquement à titre informatif, afin d’indiquer les références du matériel utilisé et, lorsque cela est pertinent, sa source d’approvisionnement.
Ces mentions ne constituent pas de la publicité, un partenariat commercial ou une recommandation rémunérée. BATLab112 n’est pas rémunéré pour la présentation de ces produits ou de ces fournisseurs.

Liste du matériel support

DésignationQtéRéférenceSource
Platine de prototype1Breadboard 830 NeufTechwww.amazon.fr
Alimentation 5VDC2USB
Alimentation 6VDC1Servomoteurs

Remarque : Les composants des alimentations électriques seront spécifiquement traités dans un prochain article.

Liste des composants utilisés

DésignationQtéRéférenceSource
Unité de contrôle1Carte Arduino Duestore.arduino.cc
Bouton rotatif8Potentiomètrewww.amazon.fr
Bouton poussoir6Bouton poussoir tactilewww.amazon.fr
Voyant rouge2Led 3mm rougewww.amazon.fr
Voyant bleu3Led 3mm bleuwww.amazon.fr
Voyant vert5Led 3mm vertewww.amazon.fr
*9Résistance

Schéma de câblage

Une première version du schéma de câblage de la commande des bras robotisés

Pour cette première version, le schéma permet de représenter l’ensemble des connexions entre l’Arduino Due, les potentiomètres, les boutons poussoirs, les LED et les servomoteurs. Cette étape est essentielle dans la démarche de conception du projet. Même lorsqu’une électronique est réalisée sous forme de prototype sur breadboard, le schéma constitue la référence permettant de comprendre l’architecture du système et de préparer ses évolutions.

Un schéma électronique réalisé avec le logiciel KiCad.

KiCad dans le projet BATLab112 :

Dans le projet BATLab112, KiCad est utilisé pour concevoir et documenter les circuits électroniques nécessaires au fonctionnement du diorama. Il permet notamment de réaliser les schémas électriques et de concevoir les circuits imprimés (PCB) qui assurent l’interface entre les systèmes de commande, les capteurs et les différents équipements de la Batcave.

KiCad est une suite logicielle open source pour la conception électronique.

Le schéma électronique de la commande des bras robotisés

Développement du programme Arduino

Le programme développé pour cette première version constitue avant tout un prototype fonctionnel. L’objectif est de vérifier que la carte Arduino Due est capable de gérer simultanément les différentes fonctions nécessaires à la commande des bras. Le code n’est donc pas encore optimisé pour une utilisation définitive. Cette distinction est importante dans la démarche BATLab112 : le prototype logiciel sert d’abord à valider le fonctionnement avant d’engager un travail d’optimisation et d’industrialisation de l’architecture.

Validation technique et fonctionnelle

La maquette du bras robotisé

Pour valider la commande électronique, une maquette du bras robotisé est réalisée. Le choix du matériau peut sembler surprenant : certaines parties sont fabriquées à partir d’emballages de briques de jus de fruit. Cette solution répond à une logique simple de prototypage. Le matériau est suffisamment léger et résistant pour permettre la réalisation des assemblages nécessaires. Sa surface présente par ailleurs un aspect proche de celui de l’aluminium, ce qui permet d’obtenir un résultat visuel acceptable pour une maquette expérimentale.

La maquette ne cherche donc pas à reproduire parfaitement le modèle 3D définitif. Son rôle est avant tout de fournir un support mécanique permettant de vérifier le comportement de l’électronique. Cette distinction entre prototype fonctionnel et prototype esthétique est importante dans le développement du projet BATLab112.

La vidéo du mode automatique

Premiers essais

Les premiers essais permettent de confirmer le fonctionnement général de la chaîne de commande. Les servomoteurs répondent aux consignes envoyées par l’Arduino et les différents modes de fonctionnement peuvent être expérimentés. La validation est donc positive sur le plan électronique.

En revanche, les essais mettent également en évidence les limites de la maquette mécanique. Sa qualité de fabrication et sa rigidité insuffisante provoquent notamment des vibrations et des perturbations dans les mouvements. Il devient alors difficile de déterminer précisément si certaines limitations proviennent de l’électronique, du servomoteur ou de la mécanique. Cette difficulté est caractéristique d’une phase de prototypage : plusieurs sous-systèmes interagissent simultanément et doivent progressivement être isolés afin d’identifier l’origine des problèmes.

Les limites identifiées par cette première version

La réalisation de cette V1 permet surtout d’identifier les améliorations nécessaires pour la suite du projet.

Une interface de commande trop rudimentaire

Les potentiomètres utilisés pour la commande manuelle nécessitent initialement l’utilisation d’un tournevis. Cette solution est acceptable pour un prototype électronique mais difficilement compatible avec une future console de commande intégrée au diorama.

Évolution envisagée : équiper les potentiomètres de boutons afin de disposer d’une véritable interface opérateur.

Une programmation trop dépendante du code Arduino

En mode automatique, les positions sont directement enregistrées dans le programme. Chaque modification d’une séquence impose donc une nouvelle programmation de la carte. Cette méthode devient rapidement contraignante.

Évolution envisagée : développer une interface permettant à l’utilisateur de définir et d’enregistrer les positions sans modifier directement le programme. Un clavier associé à un écran, voire un écran tactile, constitue une piste possible.

Une capacité d’apprentissage limitée

Le mode apprentissage permet de mémoriser seulement un nombre limité de positions. Cinq positions constituent une capacité suffisante pour démontrer le principe mais deviennent rapidement insuffisantes pour réaliser des trajectoires complexes.

Évolution envisagée : augmenter la capacité de mémorisation et développer une interface permettant de gérer les séquences de manière plus intuitive.

Des mouvements encore trop saccadés

Les premiers essais automatiques mettent également en évidence une limitation du programme. Les servomoteurs sont commandés successivement pour atteindre les différentes positions. Le mouvement global du bras apparaît alors lent et décomposé. Un véritable mouvement coordonné nécessiterait au contraire que plusieurs articulations évoluent simultanément afin de produire une trajectoire plus fluide.

Évolution envisagée : développer un pilotage simultané des différents servomoteurs et travailler sur la gestion des trajectoires.

Le problème du couple moteur

Les essais permettent également de mettre en évidence une interrogation concernant le choix des servomoteurs. Le servomoteur utilisé pour l’articulation de l’épaule semble, dans certaines configurations, manquer de couple. Il faut toutefois rester prudent dans l’interprétation de ce résultat. La maquette mécanique utilisée pour les essais présente des défauts de fabrication et des phénomènes de vibration. Il est donc difficile d’attribuer directement cette faiblesse au seul servomoteur.

Cette observation conduit néanmoins à intégrer la question du couple disponible dans les étapes suivantes de conception. Le dimensionnement mécanique du bras doit en effet être associé au choix de l’actionneur. Un moteur suffisamment puissant sur le papier peut se révéler insuffisant si la géométrie du bras, la masse des éléments mobiles ou les bras de levier augmentent les efforts nécessaires.

Une première validation, mais surtout une étape de conception

Cette première version de l’électronique de commande remplit donc son objectif principal. Elle permet de vérifier que le principe général fonctionne :

potentiomètres → Arduino Due → commande des servomoteurs → mouvements des articulations.

Elle permet également d’expérimenter trois niveaux de fonctionnement :

  • commande directe ;
  • exécution automatique ;
  • apprentissage et restitution d’une séquence.

Mais l’intérêt principal de cette V1 réside peut-être dans les problèmes qu’elle permet de révéler. L’expérimentation met en évidence les limites de l’interface, de la programmation, de la mémorisation des trajectoires, de la synchronisation des mouvements et du dimensionnement des actionneurs. Autrement dit, la première version ne constitue pas l’aboutissement du système de commande.

De la maquette à l’intégration dans la Batcave

La réalisation de cette électronique doit être replacée dans l’évolution générale des bras robotisés du projet BATLab112. Après la validation du principe de commande, les travaux se poursuivent sur la conception mécanique et la réalisation du prototype des bras. La modélisation 3D permet notamment de définir un bras à quatre degrés de liberté et d’étudier son intégration dans l’espace contraint de l’atelier de la Batcave.

Le prototype mécanique réalisé ultérieurement permet alors de confronter les choix de conception aux contraintes réelles de fabrication, de motorisation et de mouvement. Les essais mettent notamment en évidence des phénomènes d’oscillation du bras et conduisent à explorer différentes pistes concernant l’alimentation des servomoteurs, le signal PWM et le choix de l’actionneur de l’épaule.

12. Conclusion

La première électronique de commande des bras robotisés constitue une étape fondatrice du développement du système. Construite autour d’une Arduino Due et de servomoteurs, elle permet de valider les principes essentiels de commande et d’expérimenter les trois fonctions envisagées initialement : manuel, automatique et apprentissage.

Les essais montrent cependant qu’une architecture fonctionnelle ne suffit pas à obtenir un système réellement satisfaisant. L’évolution devra porter simultanément sur plusieurs niveaux :

  • l’interface opérateur ;
  • la gestion des trajectoires ;
  • la synchronisation des articulations ;
  • la capacité de mémorisation ;
  • l’alimentation électrique ;
  • le dimensionnement des actionneurs ;
  • la conception mécanique ;
  • l’intégration de l’ensemble dans le diorama.

Cette V1 doit donc être considérée comme une étape expérimentale dans la construction du système robotique de la Batcave, plutôt que comme une solution définitive.

C’est précisément ce qui fait son intérêt dans le cadre du projet BATLab112 : la maquette permet de transformer une idée issue de la fiction en un problème concret d’ingénierie, puis de confronter progressivement la conception aux contraintes réelles de l’électronique, de la mécanique et de l’automatisation.

Voir aussi

Articles – Bras robotiques

Articles – Prototypes

2 réflexions sur “Commande du bras robotique .V1

  1. Manine zemallach ouarri Ali 31 juillet 2020 / 8 h 13 min

    Bravo Stéphane. bon continuation

    • Stef 31 juillet 2020 / 9 h 17 min

      Merci Ali !

Laisser un commentaire