Conception détaillée de la console de commande BATLab112 : optimisation du pupitre, des cartes Arduino et de l’intégration électronique

Cliquer pour masquer

Résumé

Cet article s’inscrit dans la continuité de la série consacrée à la conception de la console de commande des équipements du diorama BATLab112. Il fait suite à l’article présentant la réalisation de la première version opérationnelle de la console, dont l’objectif principal était de valider les choix technologiques retenus au travers d’un prototype fonctionnel.… Lire…

Première publication :

Dernière mise à jour :

Temps de lecture :

9–14 minutes

Article précédent :

Contexte et objectifs de l’évolution de la console de commande du diorama BATLab112

Introduction

Cet article s’inscrit dans la continuité de la série consacrée à la conception de la console de commande des équipements du diorama BATLab112. Il fait suite à l’article présentant la réalisation de la première version opérationnelle de la console, dont l’objectif principal était de valider les choix technologiques retenus au travers d’un prototype fonctionnel.

Si cet article précédent mettait principalement en évidence la démarche expérimentale ayant conduit à la réalisation de ce premier modèle, il ne détaillait pas l’ensemble du travail de conception mécanique et électronique réalisé en parallèle depuis la phase de conception préliminaire jusqu’à l’aboutissement du prototype.

Cette nouvelle publication revient donc sur cette étape essentielle afin d’expliquer les évolutions qui ont conduit à la version actuelle de la console.

Retour d’expérience sur le premier prototype de la console de commande

L’analyse critique du prototype a mis en évidence deux axes d’amélioration majeurs qui conditionnent directement l’intégration de la console au sein du diorama ainsi que la fiabilité de son fonctionnement.

Le premier concerne la conception mécanique du pupitre. Les dimensions initiales avaient été définies lors de la phase de conception préliminaire en conciliant deux contraintes : l’encombrement disponible sur la plateforme accueillant l’ensemble des consoles et les dimensions de la carte électronique de prototypage utilisée pour développer le circuit imprimé regroupant les commandes manuelles (interrupteurs, boutons-poussoirs, voyants LED et autres organes de commande).

Si cette approche s’est révélée suffisante pour réaliser un premier prototype, les essais d’intégration ont rapidement montré que le volume interne du pupitre était insuffisant pour accueillir l’ensemble des cartes électroniques, du câblage et des différents connecteurs nécessaires à une exploitation fiable et à une maintenance aisée.

Optimisation de la conception mécanique du pupitre

Cette première limitation a conduit à une révision complète de la géométrie du pupitre. Au-delà de l’augmentation du volume interne, cette évolution a nécessité une réflexion globale sur l’intégration de la console au sein du diorama afin de préserver son esthétique tout en améliorant son accessibilité, son assemblage et son évolutivité.

Cette nouvelle conception s’accompagne également d’adaptations de la structure supportant les consoles afin de garantir une intégration cohérente avec les autres équipements de la plateforme de contrôle.

Refonte de l’architecture électronique de la console

Le second enseignement concerne l’architecture électronique de la console. Les essais réalisés avec les écrans TFT couleur de 2,8 pouces ont montré que leur technologie ne permettait pas un pilotage simultané satisfaisant par une unique carte Arduino Mega sans développer une électronique d’interface spécifique permettant de gérer les deux afficheurs de manière séquentielle.

Une telle solution aurait considérablement augmenté la complexité du système, multiplié les risques de dysfonctionnement et réduit la fréquence de rafraîchissement des affichages. Afin de conserver une architecture simple, robuste et évolutive, le choix a donc été revu en profondeur, conduisant notamment au remplacement de l’une des cartes Arduino Uno initialement prévues par une carte Arduino Mega mieux adaptée aux nouvelles contraintes fonctionnelles.

Les objectifs de cette nouvelle phase de conception

Cet article présente en détail les évolutions apportées à la console de commande à la suite de ce retour d’expérience. Il décrit les nouveaux choix de conception mécanique, leurs conséquences sur l’architecture générale du diorama, ainsi que les évolutions de l’électronique de commande et de l’organisation des cartes Arduino. L’ensemble de ces modifications illustre la démarche d’amélioration continue mise en œuvre tout au long du développement du projet BATLab112 afin d’aboutir à une solution à la fois réaliste, fiable, évolutive et facilement maintenable.

Évolution de la conception de la console de commande sous FreeCAD V1.1.1

Migration vers FreeCAD V1.1.1 : une opportunité pour reprendre la conception

Depuis le lancement du projet BATLab112, FreeCAD constitue l’outil central de conception assistée par ordinateur (CAO) utilisé pour développer l’ensemble des éléments mécaniques et une partie de l’architecture électronique du diorama de la Batcave à l’échelle 1/12. Au fil des années, le logiciel a connu une évolution constante, tant sur le plan des performances que de la stabilité, jusqu’à la publication de la version 1.1.1, disponible au moment de la rédaction de cet article.

La migration de l’ensemble des fichiers de conception vers cette nouvelle version a constitué une opportunité de réexaminer certains modèles développés lors des premières phases du projet. C’est dans ce contexte qu’a été engagée la reprise complète de la conception détaillée de la console de commande, avec pour objectif d’intégrer les enseignements tirés des premiers prototypes tout en tirant parti des nouvelles fonctionnalités offertes par FreeCAD.

Optimisation du modèle 3D et augmentation du volume interne du pupitre

La principale évolution concerne la conception mécanique du pupitre de commande. La reprise du dessin des flancs, réalisés par impression 3D, a permis d’augmenter significativement le volume interne disponible. Cette modification améliore l’intégration des cartes électroniques, du câblage et des différents organes de commande, tout en conservant les proportions générales de la console à l’échelle du diorama.

Au-delà de cette optimisation technique, cette reprise de conception constitue également un retour sur les premières étapes du développement du projet BATLab112. L’expérience acquise au fil des années dans l’utilisation de FreeCAD met aujourd’hui en évidence plusieurs choix de modélisation qui, sans être bloquants, pouvaient être améliorés afin d’obtenir un modèle numérique plus robuste, plus cohérent et plus facilement maintenable. Cette nouvelle version est ainsi l’occasion de corriger ces imperfections et d’appliquer des méthodes de conception désormais maîtrisées.

Les photographies présentées dans cette section témoignent également de l’évolution progressive du projet. Elles montrent notamment les premières pièces imprimées en PLA gris, réalisées au début de l’aventure BATLab112. Au-delà de leur intérêt technique, ces images rappellent le chemin parcouru et soulignent l’importance des collaborations qui ont accompagné les premières phases du développement. Avant que le projet ne dispose de ses propres moyens de conception et de fabrication, l’appui de contributeurs extérieurs a joué un rôle déterminant dans la réalisation des premiers prototypes, contribuant ainsi à poser les bases de l’évolution actuelle de la console de commande.

Amélioration de la fiabilité du câblage des écrans TFT

Les essais réalisés sur les premières versions des consoles de commande ont également mis en évidence une faiblesse inattendue concernant le raccordement des écrans TFT aux cartes Arduino Mega. Les premiers prototypes utilisaient des câbles Dupont standards, largement répandus dans le prototypage électronique. L’expérience acquise au cours des différentes phases de tests a cependant montré que leur qualité de fabrication était insuffisante pour garantir une utilisation durable.

La plupart de ces câbles sont constitués de conducteurs de faible section (28 AWG) protégés par une gaine en PVC. Avec les manipulations répétées et le vieillissement des matériaux, ces conducteurs deviennent plus sensibles aux ruptures internes et aux mauvais contacts, générant des dysfonctionnements intermittents particulièrement difficiles à diagnostiquer.

Une solution consistait à connecter directement les écrans sur les connecteurs des cartes Arduino Mega afin de supprimer totalement ce câblage intermédiaire. Si cette approche présentait l’avantage d’améliorer la fiabilité des connexions, elle n’a finalement pas été retenue. L’encombrement de l’ensemble constitué par la carte Arduino et son écran aurait nécessité d’augmenter la largeur de chaque console, remettant en cause l’implantation des quatre postes de commande sur la plateforme de contrôle du diorama.

Le maintien d’un câblage distinct répond également à l’un des objectifs fondamentaux du projet BATLab112 : sa vocation pédagogique. En laissant visibles les liaisons entre les différents composants électroniques, la console facilite la compréhension de son architecture et permet d’illustrer concrètement les interactions entre les cartes de commande, les périphériques d’affichage et les différents organes de contrôle. Ce choix privilégie ainsi la lisibilité du système tout en conservant une architecture proche de celle rencontrée dans de nombreux équipements industriels.

Les recherches menées depuis la réalisation du premier prototype ont toutefois permis d’identifier une alternative plus adaptée. Les nouveaux faisceaux utilisent des conducteurs de section plus importante (22 AWG) associés à une isolation en silicone, offrant une bien meilleure résistance aux flexions répétées et une fiabilité accrue des connexions. Cette évolution permet de conserver l’architecture de câblage initiale tout en améliorant sensiblement la robustesse et la pérennité de la console de commande.

Optimisation du PCB des commandes manuelles grâce à l’impression 3D

La reprise de la conception de la console a également porté sur le circuit imprimé regroupant l’ensemble des commandes manuelles. Si l’implantation des composants réalisée lors de la conception préliminaire puis validée sur le prototype fonctionnel ne présentait aucune anomalie sur le plan électrique, elle révélait en revanche une faiblesse de conception affectant le réalisme et la qualité esthétique du panneau de commande.

Lors des premières phases du projet, la maîtrise encore limitée de FreeCAD, combinée à l’absence de solution simple pour fabriquer des pièces de précision — le projet ne disposant pas encore d’une imprimante 3D — avait conduit à implanter certains composants directement sur le circuit imprimé sans dispositif permettant de contrôler précisément leur positionnement en hauteur. Les interrupteurs, boutons-poussoirs et voyants dépassaient ainsi insuffisamment de la façade de la console, ce qui réduisait le réalisme de l’ensemble malgré un fonctionnement parfaitement conforme aux attentes.

La nouvelle version corrige cette limitation en intégrant des supports spécifiquement conçus pour positionner chaque composant à une hauteur parfaitement maîtrisée lors de son montage sur le circuit imprimé. Ces supports, modélisés sous FreeCAD puis fabriquées par impression 3D, garantissent une implantation reproductible tout en simplifiant les opérations d’assemblage de la console.

Amélioration du réalisme du panneau de commande de la console

L’optimisation de l’implantation des composants ne répond pas uniquement à des exigences de précision mécanique. Elle ouvre également de nouvelles possibilités dans la conception du panneau de couverture des commandes manuelles, en permettant de maîtriser avec davantage de précision la position et le relief de chaque organe de commande.

Grâce à cette évolution, les interrupteurs, boutons-poussoirs et voyants présentent désormais des proportions et un débattement plus proches de ceux observés sur les pupitres industriels qui ont servi de référence tout au long de la conception du projet BATLab112. Cette fidélité accrue contribue à renforcer la cohérence visuelle de la console tout en améliorant son ergonomie et sa lisibilité.

Au-delà de l’aspect esthétique, cette évolution traduit la volonté de reproduire le plus fidèlement possible les caractéristiques des équipements réels à l’échelle 1/12. Elle participe ainsi à la qualité globale du diorama, où chaque détail de conception contribue à créer un ensemble à la fois crédible sur le plan technique et immersif sur le plan visuel.

Conclusion

La reprise de la conception détaillée de la console de commande illustre parfaitement la démarche d’amélioration continue qui accompagne le développement du projet BATLab112. Loin de remettre en cause les choix réalisés lors de la conception préliminaire ou les enseignements tirés du premier prototype fonctionnel, cette nouvelle phase de développement s’appuie au contraire sur le retour d’expérience accumulé au fil des essais, des validations techniques et des évolutions des outils de conception.

La migration vers FreeCAD V1.1.1 a constitué une opportunité de revisiter l’ensemble du modèle numérique afin d’optimiser aussi bien l’architecture mécanique que l’intégration électronique de la console. L’augmentation du volume interne du pupitre, l’amélioration de l’implantation des composants sur le circuit imprimé, l’évolution du câblage des écrans et la révision de l’architecture autour des cartes Arduino témoignent de la volonté constante de concilier réalisme, fiabilité, facilité d’assemblage et maintenabilité.

Ces évolutions mettent également en évidence la montée en maturité du projet. Les premières étapes étaient principalement consacrées à la validation des principes de fonctionnement, tandis que les itérations actuelles permettent d’affiner les détails de conception, d’améliorer la qualité perçue des différents sous-ensembles et de renforcer leur robustesse. Cette progression est caractéristique d’une véritable démarche d’ingénierie, où chaque prototype contribue à enrichir les connaissances et à orienter les développements suivants.

Enfin, cette nouvelle version de la console de commande répond pleinement aux ambitions du projet BATLab112, qui ne se limite pas à la réalisation d’un diorama fonctionnel de la Batcave à l’échelle 1/12. Elle participe également à la création d’un support technique et pédagogique destiné à illustrer les principes de la conception mécanique, de l’électronique embarquée, de la fabrication additive et de la programmation des systèmes embarqués. Chaque évolution documentée contribue ainsi à partager les choix de conception, les difficultés rencontrées et les solutions retenues, dans une logique de transmission des connaissances et de valorisation des méthodes de développement.

Les prochains articles seront consacrés à la finalisation du modèle numérique, à la fabrication des nouvelles pièces, à l’assemblage de la console de commande et aux essais de validation fonctionnelle qui permettront de confirmer les performances de cette nouvelle architecture avant son intégration définitive au sein du diorama BATLab112.

Voir aussi

Articles – Console de commande

Story – Console de commande

Articles – Conception détaillée

Conception de l’architecture électronique du pont élévateur du projet BATLab112 : schémas KiCAD, Arduino et régulation des moteurs

Cliquer pour masquer

Résumé

Cet article s’inscrit dans la continuité de la publication consacrée au test d’intégration de la nouvelle architecture électronique du système de commande du pont élévateur du projet BATLab112. Les essais réalisés ont permis de valider le fonctionnement de cette nouvelle conception, tant sur les plans matériel que logiciel, confirmant ainsi sa conformité aux objectifs fonctionnels…

Première publication :

Dernière mise à jour :

Temps de lecture :

16–24 minutes

Validation de l’architecture électronique après les essais d’intégration

Cet article s’inscrit dans la continuité de la publication consacrée au test d’intégration de la nouvelle architecture électronique du système de commande du pont élévateur du projet BATLab112. Les essais réalisés ont permis de valider le fonctionnement de cette nouvelle conception, tant sur les plans matériel que logiciel, confirmant ainsi sa conformité aux objectifs fonctionnels définis lors de la phase de conception.

Cette validation constitue une étape déterminante dans le développement du diorama. Elle marque le passage entre la phase de vérification fonctionnelle et celle de la documentation technique, dont l’objectif est de présenter en détail l’organisation de l’architecture électronique ainsi que les choix d’ingénierie qui ont conduit à sa conception.

Une architecture électronique entièrement conçue sous KiCAD

Comme l’ensemble des développements électroniques du projet BATLab112, les schémas du système de commande du pont élévateur ont été réalisés avec le logiciel KiCAD. Cet environnement de conception électronique (EDA) permet d’organiser un projet complexe sous la forme d’une arborescence de schémas hiérarchiques réunis dans un fichier unique.

Cette méthode de conception présente plusieurs avantages. Elle améliore la lisibilité de la documentation, facilite l’identification des différents sous-ensembles fonctionnels et garantit une parfaite traçabilité des évolutions apportées au système tout au long de son développement. Elle reflète également la démarche méthodique d’ingénierie adoptée pour l’ensemble du projet BATLab112.

Une organisation hiérarchique pour comprendre progressivement le système de commande

L’architecture électronique est volontairement organisée selon plusieurs niveaux hiérarchiques. Cette structuration permet de découvrir progressivement le système de commande, en passant d’une vision globale de l’installation jusqu’au détail de chacun des circuits imprimés (PCB).

Le premier niveau de l’arborescence offre une vue d’ensemble des principaux équipements qui composent le système de commande du pont élévateur. Les niveaux suivants détaillent ensuite l’architecture interne de chacun de ces sous-ensembles afin de mettre en évidence leurs fonctions, leurs interactions et leur contribution au fonctionnement global de l’installation.

Niveau 1 : Vue d’ensemble de l’architecture électronique du système de commande

Le premier niveau de l’arborescence des schémas présente l’ensemble des équipements constituant le système de commande du pont élévateur. Cette représentation globale permet d’identifier immédiatement les principaux sous-systèmes ainsi que les liaisons électriques assurant leur fonctionnement coordonné.

L’architecture s’articule autour de plusieurs ensembles fonctionnels spécialisés, chacun remplissant un rôle précis dans le pilotage, l’alimentation et le contrôle du pont élévateur.

Armoires de distribution électrique : alimentation des composants électroniques et des moteurs

Les armoires de distribution électrique assurent la fourniture des différentes tensions nécessaires au fonctionnement du système. 

  • Une alimentation de 5 V courant continu (5 VDC) est dédiée aux composants électroniques tels que les cartes Arduino, les relais, les diodes électroluminescentes (LED) et les différents circuits de commande.
  • Une seconde alimentation en 12 V courant continu (12 VDC) est réservée aux moteurs électriques assurant la transmission du mouvement vers les différents axes du pont élévateur.

Le choix de cette tension d’alimentation, distincte de celle utilisée pour les composants électroniques, résulte des caractéristiques des moteurs retenus lors de la phase de conception. Ceux-ci ont été dimensionnés afin de développer le couple nécessaire à l’entraînement des différents axes du pont élévateur, ce qui impose une alimentation en 12 VDC adaptée à leurs performances électromécaniques.

Plateformes moteurs : transmission du mouvement et mesure de la vitesse de rotation

Le système comprend quatre plateformes moteurs, chacune intégrant les éléments usinants : 

  • Un moteur électrique chargé d’entraîner un axe du pont élévateur.
  • Un capteur optique permettant de mesurer sa fréquence de rotation.
  • Une armoire de raccordement électrique regroupant les connexions de puissance et les liaisons des capteurs.

Cette organisation modulaire facilite les opérations de câblage, de maintenance et de remplacement des équipements.

Armoires de commande : cœur de l’électronique de contrôle du pont élévateur

L’ensemble est piloté par deux armoires électriques intégrant l’électronique de commande du système. Elles regroupent les cartes électroniques assurant le traitement des informations provenant des capteurs, le pilotage des moteurs, la gestion des interfaces d’entrée et de sortie ainsi que les fonctions de sécurité nécessaires au fonctionnement du pont élévateur.

Ces armoires constituent le cœur de l’architecture électronique développée pour BATLab112 et assurent la coordination de l’ensemble des équipements afin de garantir un fonctionnement fiable, reproductible et évolutif du diorama.

Console de commande : centre de pilotage et de supervision du pont élévateur

Les quatre consoles de commande développées dans le cadre du projet BATLab112 reposent sur une architecture mécanique commune. Ce design générique constitue une plateforme standardisée sur laquelle viennent s’intégrer des sous-ensembles électroniques spécifiques à chaque équipement industriel représenté dans le diorama. Cette approche modulaire facilite la conception, la maintenance et les évolutions futures, tout en garantissant une ergonomie homogène entre les différentes consoles.

La console de commande constitue le centre névralgique de l’architecture électronique du système de commande du pont élévateur. Elle centralise l’ensemble des fonctions de pilotage, qu’il s’agisse des commandes manuelles utilisées lors des phases d’exploitation ou des commandes automatiques exécutées par le système de contrôle.

En complément de ces fonctions de commande, la console assure la réception et le traitement des informations transmises par les armoires électriques de contrôle et d’interface ainsi que par les différents capteurs de fin de course répartis sur le pont élévateur. Ces données sont exploitées pour restituer en temps réel l’état de fonctionnement de l’installation, notamment la position des différents axes, l’état des mouvements en cours et les informations nécessaires à la supervision du système.

Si tous les équipements apparaissent dans la vue d’ensemble de l’architecture, ils ne nécessitent pas le même niveau de description. Certains sous-ensembles assurent essentiellement des fonctions de raccordement électrique, tandis que d’autres concentrent les fonctions de traitement, de commande et de régulation qui constituent le cœur du système électronique. Les développements qui suivent portent donc principalement sur ces derniers.

Périmètre de présentation des schémas électroniques

Les niveaux hiérarchiques suivants de l’arborescence des schémas électroniques ne détaillent pas les armoires de distribution électrique ni les plateformes motorisées. En effet, ces sous-ensembles se limitent essentiellement à des fonctions de raccordement électrique réalisées au moyen de borniers, sans intégrer de circuits électroniques de commande ou de traitement de l’information.

Leur représentation détaillée n’apporterait donc aucun élément supplémentaire à la compréhension de l’architecture électronique globale du système de commande du pont élévateur. L’article se concentre ainsi sur les schémas des sous-ensembles assurant les fonctions de contrôle, d’interface et de pilotage, qui constituent le cœur fonctionnel de cette architecture.

Cette première représentation fournit une vision globale de l’architecture du système et constitue le point de départ de l’analyse détaillée développée dans les sections suivantes. Chaque niveau de l’arborescence apportera ensuite un degré supplémentaire de précision afin de présenter successivement les armoires électroniques, la console de commande, puis les différents circuits imprimés qui composent le système.

Niveau 2 – Décomposition fonctionnelle des principaux sous-ensembles électroniques

Après avoir présenté l’organisation générale du système de commande, le deuxième niveau de l’arborescence détaille l’architecture interne des principaux sous-ensembles électroniques. Cette approche permet de comprendre comment les différentes fonctions sont réparties entre les cartes électroniques, les microcontrôleurs et les interfaces de puissance afin d’assurer le pilotage, la régulation et la supervision du pont élévateur.

Architecture électronique de la console de commande du pont élévateur

Le deuxième niveau de l’arborescence des schémas électroniques présente l’organisation interne de la console de commande et détaille les différents sous-ensembles électroniques qui la composent.

Dans le cas de la console de commande du pont élévateur, l’architecture électronique s’articule autour de quatre sous-ensembles fonctionnels principaux :

  • les cartes électroniques (PCB) dédiées aux commandes manuelles, qui regroupent l’ensemble des organes de pilotage mis à la disposition de l’utilisateur. Elles permettent notamment de commander la montée et la descente du pont élévateur, ainsi que les différentes fonctions de contrôle accessibles depuis la console ;
  • les cartes électroniques (PCB) assurant les fonctions spécifiques au contrôle et au pilotage du pont élévateur. Elles permettent notamment de définir la consigne de référence de la vitesse de rotation des moteurs électriques, afin d’adapter la vitesse de déplacement du pont élévateur en fonction des conditions d’exploitation retenues ;
  • les cartes électroniques (PCB) d’interface avec les capteurs de fin de course, chargées de conditionner et de transmettre les informations issues des différents détecteurs répartis sur l’installation. Elles assurent en particulier l’arrêt automatique des moteurs lorsque le pont élévateur atteint sa position haute ou sa position basse, garantissant ainsi le respect des limites mécaniques de fonctionnement ;
  • les cartes Arduino Mega et les écrans TFT de 2,8 pouces, qui assurent le traitement des informations, la communication avec les armoires électroniques de contrôle et d’interface, ainsi que l’affichage en temps réel de l’état du système de commande et de la position du pont élévateur.

Cette organisation hiérarchique met en évidence la séparation des fonctions de commande, d’acquisition des informations, de traitement et de supervision, conformément aux principes d’une architecture électronique modulaire, évolutive et facilement maintenable.

La console de commande constitue l’interface entre l’utilisateur et le système. Son fonctionnement repose cependant sur plusieurs armoires électroniques qui assurent le traitement des informations, la régulation des moteurs et la commande de puissance. L’étude de leur architecture permet de mieux comprendre la répartition des fonctions au sein du système de commande.

Architecture électronique de l’armoire de contrôle et d’interface de puissance des moteurs

Le deuxième niveau de l’arborescence des schémas électroniques présente l’organisation interne de l’armoire électrique d’interface de puissance des moteurs du pont élévateur. Cette armoire constitue l’interface entre le système de commande et les actionneurs, en assurant à la fois la distribution des signaux de commande, la gestion de la puissance électrique et les fonctions de sécurité nécessaires au fonctionnement de l’installation.

Son architecture électronique est organisée autour de trois sous-ensembles fonctionnels principaux :

  • Un circuit imprimé (PCB) assurant les fonctions de bornier de raccordement électrique et de sectionneur. Il centralise les liaisons électriques entre les différents équipements et permet l’isolement électrique de l’armoire afin de sécuriser les opérations de maintenance ou les interventions manuelles sur les composants électroniques ;
  • Un premier PCB L298N intégrant un double pont en H, chargé de l’interface de puissance avec deux des moteurs électriques. Il assure le pilotage du sens de rotation ainsi que la régulation de leur vitesse à partir des consignes transmises par le système de commande ;
  • Un second PCB L298N intégrant un double pont en H, assurant les mêmes fonctions pour les deux autres moteurs électriques du pont élévateur. Cette répartition permet de commander indépendamment les quatre moteurs tout en conservant une architecture modulaire, évolutive et facilement maintenable.

Alors que l’armoire d’interface de puissance assure l’alimentation et le pilotage électrique des moteurs, une seconde armoire est dédiée aux fonctions de contrôle et de régulation. Cette séparation des fonctions constitue un choix d’architecture qui améliore la modularité du système tout en simplifiant les opérations de développement, de maintenance et d’évolution.

Architecture électronique de l’armoire de contrôle et de régulation de la vitesse des moteurs

Le deuxième niveau de l’arborescence des schémas électroniques présente l’organisation interne de l’armoire électrique de contrôle et de régulation de la vitesse de rotation des moteurs du pont élévateur. Cette armoire assure le traitement des informations issues des capteurs de vitesse, l’exécution des algorithmes de régulation ainsi que la génération des consignes destinées à l’armoire d’interface de puissance.

À l’image de l’armoire de contrôle et d’interface de puissance, elle intègre :

  • Un circuit imprimé (PCB) assurant les fonctions de bornier de raccordement électrique et de sectionneur. Ce sous-ensemble centralise les connexions électriques de l’armoire tout en permettant son isolement lors des opérations de maintenance ou des interventions sur les composants électroniques.
  • Une carte Arduino Nano R4, le coeur du système, dont le programme met en œuvre les algorithmes de régulation de la vitesse des quatre moteurs électriques. Chaque moteur est piloté indépendamment à partir des mesures fournies par son capteur de vitesse, ce qui permet de compenser les écarts de fonctionnement entre les motorisations et de garantir la parfaite synchronisation de leurs mouvements. Cette régulation indépendante contribue à maintenir l’horizontalité et la stabilité du pont élévateur tout au long de ses déplacements verticaux.
  • Un écran OLED i2c fournissant en temps réel des informations synthétiques sur la vitesse de rotation de chacun des moteurs ainsi que sur l’état de fonctionnement du système de régulation. Implanté au plus près des équipements électroniques, cet affichage constitue un outil de diagnostic particulièrement utile lors des phases de développement, de mise au point des algorithmes de régulation et de réglage des paramètres de fonctionnement du pont élévateur.

Niveau 3 – Schémas détaillés des circuits imprimés et des composants électroniques

Le troisième et dernier niveau de l’arborescence correspond au degré de détail le plus fin de la documentation électronique. Chaque feuille hiérarchique décrit soit un composant complexe, tel qu’une carte Arduino ou un écran TFT, soit le schéma complet d’un circuit imprimé développé spécifiquement pour le projet BATLab112. Cette organisation garantit une parfaite traçabilité entre l’architecture fonctionnelle du système et sa réalisation électronique.

Carte électronique de centralisation des commandes manuelles

Architecture du PCB010 : une organisation modulaire des commandes manuelles

Le PCB010, dédié à la centralisation des commandes manuelles de la console du pont élévateur, est constitué de deux circuits imprimés distincts. Ce découpage résulte d’un choix de conception visant à optimiser l’implantation de l’électronique au sein de la console de commande, à simplifier le câblage et à faciliter les opérations de maintenance ainsi que les évolutions futures du système.

  • Le premier circuit imprimé regroupe l’ensemble des composants directement accessibles à l’utilisateur, tels que les commutateurs (switchs), les boutons-poussoirs et les voyants à LED, qui constituent l’interface de commande et de signalisation de la console.
  • Le second circuit imprimé est exclusivement consacré aux relais de logique câblée, assurant le traitement des commandes manuelles et la mise en œuvre des fonctions logiques nécessaires au pilotage du pont élévateur. Cette organisation contribue à améliorer la lisibilité de l’architecture électronique tout en facilitant l’intégration mécanique des différents composants dans un espace restreint.

Logique câblée : un choix d’ingénierie pour la sécurité et le réalisme du projet BATLab112

Cette architecture répond à une volonté plus large du projet BATLab112 : reproduire le plus fidèlement possible les principes de fonctionnement des installations industrielles réelles. Dans cette optique, les commandes manuelles des quatre consoles pilotant les différents équipements du diorama ont été réalisées selon une logique câblée, plutôt qu’au moyen d’un traitement logiciel intégral.

Ce choix technologique présente plusieurs avantages. Il permet tout d’abord de dissocier les fonctions de commande manuelle des traitements réalisés par les microcontrôleurs, ce qui améliore la robustesse du système et simplifie son analyse fonctionnelle. Il contribue également à renforcer la sécurité de fonctionnement, en particulier pour les équipements mettant en œuvre des mouvements mécaniques tels que le pont roulant, le pont élévateur ou la plateforme rotative.

En effet, les fonctions de commande reposent sur des relais électromécaniques dont le comportement est intrinsèquement sûr : en cas de coupure de l’alimentation électrique, leurs contacts reviennent automatiquement dans leur position de repos. Cette caractéristique facilite la mise en œuvre de fonctions de sécurité passives, sans nécessiter d’intervention logicielle, et garantit l’arrêt des mouvements dans un état prédéfini. Cette approche, largement utilisée dans les installations industrielles, renforce la sécurité des personnes et la protection des équipements tout en participant au réalisme technique recherché par le projet BATLab112.

Carte électronique de contrôle et de réglage du pont élévateur

Réglage des paramètres de fonctionnement du pont élévateur

Le PCB020 regroupe les fonctions de contrôle et de réglage des principaux paramètres de fonctionnement du pont élévateur. Son rôle est de fournir les consignes nécessaires au système de commande, notamment celles relatives à la vitesse de déplacement de l’installation, afin d’adapter le comportement des moteurs aux conditions d’exploitation retenues.

Dans sa version actuelle, cette carte électronique reprend une architecture déjà développée et validée pour le pont roulant bipoutre du projet BATLab112. Elle repose sur un montage astable à base de circuit intégré NE555, capable de générer un signal carré dont le rapport cyclique est réglable. Ce signal constitue la consigne de référence utilisée pour piloter la vitesse de rotation des moteurs du pont élévateur.

Le choix de réutiliser cette architecture illustre l’un des principes de conception appliqués au projet BATLab112 : capitaliser sur les solutions techniques déjà éprouvées afin de limiter les développements spécifiques, d’améliorer la fiabilité des nouveaux équipements et de garantir une cohérence d’ensemble entre les différents systèmes du diorama.

Une architecture susceptible d’évoluer avec le système de régulation

Bien que cette solution réponde actuellement aux besoins du système de commande, son architecture n’est pas encore définitivement figée. Les évolutions en cours d’étude concernant le PCB030, chargé de la gestion des capteurs de fin de course, pourraient conduire à revoir certaines fonctions du PCB020.

En particulier, la mise en œuvre d’un recalage automatique de l’horizontalité du pont élévateur en fin de course pourrait nécessiter une adaptation des paramètres de commande et des stratégies de pilotage des moteurs. Dans cette hypothèse, les fonctions actuellement assurées par le générateur de consigne pourraient évoluer afin de mieux s’intégrer à l’architecture globale de régulation.

Carte électronique de gestion des capteurs de fin de course du pont élévateur

Gestion des positions haute et basse du pont élévateur

Le PCB030 est dédié au raccordement et au traitement des informations issues des capteurs de fin de course du pont élévateur. Ces capteurs assurent la détection des positions extrêmes de l’installation, en fin de montée et en fin de descente, afin de déclencher automatiquement l’arrêt des moteurs lorsque le pont atteint sa position haute ou sa position basse.

Dans sa configuration actuelle, l’architecture repose sur deux capteurs de fin de course : un premier associé à la position haute et un second à la position basse. Cette solution constitue une première étape de validation du système de commande et permet d’assurer les fonctions essentielles de sécurité et de pilotage du pont élévateur.

Limites de l’architecture actuelle et perspectives d’évolution

Si cette architecture répond aux besoins fonctionnels de base, elle reste toutefois conditionnée par les performances de la régulation de vitesse des quatre moteurs. En effet, avec seulement un capteur pour chaque position extrême, le système suppose que les quatre axes du pont élévateur conservent une parfaite synchronisation tout au long des cycles successifs de montée et de descente.

Or, même si l’algorithme de régulation permet d’obtenir une excellente stabilité du pont au cours d’un déplacement et garantit ainsi des conditions de fonctionnement satisfaisantes pour le transport de la Batmobile, de très faibles écarts de synchronisation peuvent subsister entre les différents moteurs. Pris isolément, ces écarts restent négligeables, mais leur accumulation au fil des cycles de fonctionnement pourrait progressivement provoquer un défaut d’horizontalité du pont élévateur.

À terme, ce phénomène pourrait entraîner un décalage entre les quatre axes de levage, susceptible de compromettre la stabilité de la Batmobile lors de ses déplacements ou, dans le cas le plus défavorable, de provoquer un arc-boutement mécanique capable de bloquer le mouvement du pont.

Afin de supprimer ce risque, une évolution de l’architecture est actuellement à l’étude. Elle consisterait à équiper chacun des quatre axes de son propre capteur de fin de course, soit quatre capteurs pour la position haute et quatre capteurs pour la position basse. Au-delà de leur fonction de sécurité, ces capteurs permettraient de mettre en œuvre une procédure de recalage automatique de chaque axe à l’issue de chaque déplacement. Chaque cycle de montée ou de descente deviendrait ainsi une phase de réinitialisation de l’horizontalité du pont, éliminant les erreurs cumulées de synchronisation et garantissant durablement la stabilité mécanique de l’ensemble du système.

Conclusion

Une architecture électronique du diorama conçue selon les principes de l’ingénierie

La conception de l’architecture électronique du système de commande du pont élévateur constitue une étape majeure dans le développement du diorama de la Batcave projet BATLab112. Au-delà de la réalisation d’un simple système de commande, cette architecture traduit une véritable démarche d’ingénierie fondée sur la séparation des fonctions, la modularité des sous-ensembles et la hiérarchisation de la documentation technique.

L’organisation des schémas électroniques sous KiCAD reflète directement cette approche. En structurant la conception selon plusieurs niveaux de détail, depuis la vue d’ensemble du système jusqu’aux schémas des circuits imprimés, elle facilite la compréhension de l’architecture, simplifie les opérations de maintenance et garantit une parfaite traçabilité des évolutions apportées au projet. Cette méthode de conception constitue également un support précieux pour la validation fonctionnelle, le développement de nouvelles fonctionnalités et la documentation technique du diorama.

Les choix retenus, tels que la séparation des fonctions de régulation et d’interface de puissance, la commande indépendante des quatre motorisations, l’utilisation de cartes Arduino spécialisées ou encore la standardisation de la console de commande, illustrent la volonté de concevoir un système à la fois fiable, évolutif et facilement maintenable. Cette architecture offre ainsi une base robuste pour les futures évolutions du pont élévateur, tout en restant cohérente avec les principes de conception appliqués à l’ensemble des équipements industriels du projet BATLab112.

BATLab112 : un diorama pédagogique fondé sur une démarche d’ingénierie

Au-delà de ses aspects techniques, cette architecture illustre également la philosophie qui guide le développement du projet BATLab112. Bien qu’il s’agisse d’un diorama à l’échelle 1/12 inspiré de l’univers de Batman, sa conception repose sur les mêmes méthodes, outils et exigences que celles mises en œuvre dans les projets industriels. Chaque sous-ensemble est étudié, documenté, testé puis validé selon une démarche méthodique, où les choix de conception sont justifiés par des considérations fonctionnelles, mécaniques, électroniques et logicielles. Le diorama devient ainsi un véritable support d’expérimentation et de démonstration des pratiques de l’ingénierie des systèmes complexes.

Cette approche répond pleinement aux objectifs du projet BATLab112 : démontrer qu’il est possible de transposer, à l’échelle d’une maquette fonctionnelle, les méthodes de conception utilisées dans l’industrie afin de créer un système cohérent, évolutif et techniquement documenté. Au-delà de la réalisation d’un objet de démonstration, le projet a vocation à constituer une ressource pédagogique permettant d’illustrer les interactions entre la mécanique, l’électronique, l’automatisme, l’informatique embarquée et la modélisation numérique. Chaque article publié contribue ainsi à documenter cette démarche et à partager les choix d’ingénierie qui ont conduit à la réalisation progressive du diorama.

Une architecture modulaire au service des évolutions futures

Les prochains articles de cette série approfondiront chacun des sous-ensembles présentés ici. Ils détailleront notamment la conception des différents circuits imprimés (PCB), les choix de dimensionnement des interfaces électroniques, les algorithmes de régulation développés pour l’Arduino Nano R4, ainsi que les programmes assurant le pilotage de la console de commande et la supervision du pont élévateur. Cette exploration progressive permettra de suivre l’ensemble du processus de conception, depuis les premiers schémas électroniques jusqu’à la validation fonctionnelle du système complet, tout en mettant en lumière la démarche d’ingénierie qui constitue l’identité même du projet BATLab112.

Voir aussi

Articles – Pont élévateur

Story – Pont élévateur

Articles – KiCAD

Test d’intégration du système électronique de commande du pont élévateur avec Arduino dans le diorama Batcave BATLab112

Cliquer pour masquer

Résumé

Cet article présente le test d’intégration final du système de commande du pont élévateur du diorama Batcave BATLab112. Basé sur un Arduino Nano R4 pour le contrôle des moteurs et un Arduino Mega pour la console de supervision, ce système assure l’acquisition des vitesses de rotation de quatre moteurs, leur affichage sur écrans OLED et…

Première publication :

Dernière mise à jour :

Temps de lecture :

5–7 minutes

Vers la validation finale du système électronique du pont élévateur

Cet article clôt une longue série de publications consacrées au développement du système électronique de commande du pont élévateur du diorama de la Batcave du projet BATLab112. Parmi les différents équipements conçus jusqu’à présent dans le cadre de ce projet, le pont élévateur constitue l’ensemble le plus complexe sur le plan technique. Son architecture repose en effet sur le pilotage simultané de quatre moteurs électriques dont la vitesse de rotation doit être régulée avec précision. Cette exigence de synchronisation et de stabilité explique le temps particulièrement important consacré aux phases de conception, d’expérimentation et de mise au point du système.

Le présent article expose ainsi les essais d’intégration du système électronique de commande du pont élévateur réalisés avant l’assemblage mécanique final des plateformes motorisées avec les axes verticaux du mécanisme.

Armoires électriques Arduino pour le contrôle et la puissance du pont élévateur

Depuis l’article précédent, les deux armoires électriques intégrant les fonctions de contrôle et les interfaces de puissance des moteurs ont été équipées de leurs enveloppes mécaniques puis assemblées entre elles afin de constituer un module fonctionnel unique. L’esthétique générale de cet ensemble s’inspire directement des armoires électriques industrielles réelles, fréquemment regroupées de cette manière lorsqu’elles participent à un même système technique. À l’échelle 1/12, cette configuration présente également l’avantage d’améliorer la stabilité de l’ensemble et de faciliter sa manipulation lors de son intégration dans le diorama.

L’écran destiné à l’affichage des fréquences de rotation des moteurs a été intégré à l’armoire de contrôle. Le panneau de fixation de cet écran, monté sur la porte de l’armoire, intègre désormais deux voyants lumineux. Le voyant supérieur indique que l’armoire est alimentée électriquement, tout en précisant qu’aucune tension n’est encore délivrée vers les plateformes motorisées et que l’ensemble des composants internes demeure à l’arrêt. Le voyant inférieur signale quant à lui l’activation du sectionneur principal de l’armoire, entraînant l’alimentation des composants internes, notamment du microcontrôleur Arduino Nano R4, ainsi que la mise sous tension des capteurs optiques installés sur les plateformes moteurs.

Fiabilisation des capteurs optiques des plateformes moteurs

Deux des plateformes motorisées ont nécessité une intervention corrective consistant au remplacement de leurs capteurs optiques. Ces derniers se sont révélés défaillants au cours des précédentes campagnes d’essais fonctionnels. Cette opération de maintenance a permis de restaurer la fiabilité des mesures de vitesse de rotation nécessaires au fonctionnement du système de régulation.

Console de commande Arduino Mega et écran TFT pour le pont élévateur

À ce stade du développement, la console de commande centralisée est simulée par un montage expérimental composé d’un écran TFT piloté par une carte Arduino Mega ainsi que d’une plaque de prototypage regroupant les commandes manuelles simplifiées. Ce dispositif permet notamment de régler le rapport cyclique appliqué à la commande de la fréquence de rotation initiale des moteurs.

Au-delà de sa fonction essentielle de validation du bon fonctionnement global du système électronique, ce montage expérimental permet également de tester les échanges de données entre l’Arduino Nano R4 de l’armoire de contrôle et l’Arduino Mega de la console de commande, au moyen d’une liaison série assurant la transmission des informations de pilotage et de supervision.

Programmation des sketches Arduino Mega et Nano R4

Une maquette de simulation regroupant les principaux éléments du système de contrôle a été mise en œuvre afin de constituer un environnement de développement et de validation du sketch de régulation de vitesse exécuté par la carte Arduino Nano R4. Ce dispositif expérimental permet de faciliter la mise au point progressive des algorithmes de commande avant leur intégration définitive dans le système électronique embarqué.

Cette maquette expérimentale regroupe les principaux sous-ensembles nécessaires à la validation du système de commande. Elle comprend une carte Arduino Uno utilisée comme générateur de signaux PWM à fréquence variable, une carte Arduino Mega associée à un écran TFT et à une platine de prototypage simulant les organes de commande manuelle de la console centralisée, ainsi qu’une carte Arduino Nano R4 destinée à l’implémentation et à la mise au point des algorithmes de régulation de vitesse des moteurs du pont élévateur.

Arduino Mega : développement du logiciel de la console de commande TFT

Le développement du programme embarqué sur la carte Arduino Mega s’inscrit dans la continuité des travaux réalisés pour les consoles de commande des équipements précédemment développés dans le cadre du projet BATLab112, notamment la plateforme rotative et le pont roulant. Cette nouvelle version du sketch reprend l’architecture logicielle existante tout en y intégrant des fonctionnalités complémentaires, parmi lesquelles la réception de données transmises par liaison série Rx/Tx depuis le système de contrôle du pont élévateur, ainsi que leur affichage sur l’écran TFT de la console.

Ce programme demeure en cours d’évolution afin de répondre aux nouvelles exigences induites par la régulation de vitesse des moteurs du pont élévateur. Les développements futurs porteront notamment sur l’intégration de nouvelles fonctionnalités, l’amélioration de l’interface graphique utilisateur et l’optimisation des performances globales du système. Une analyse détaillée de ce code sera présentée ultérieurement lors de la conception du modèle opérationnel définitif de la console de commande du pont élévateur.

Arduino Nano R4 : programmation du système de contrôle et de régulation des moteurs

Le sketch exécuté par l’Arduino Nano R4, intégré à l’armoire électrique de contrôle, regroupe quant à lui les fonctions indispensables à la réalisation des essais d’intégration. Il assure l’acquisition des fréquences de rotation des quatre moteurs, l’affichage local de ces mesures sur un écran OLED, la transmission des valeurs mesurées vers la console de commande, ainsi que le pilotage du rapport cyclique des signaux de commande destinés aux moteurs.

Cet environnement logiciel constitue la base expérimentale nécessaire au développement progressif des algorithmes de régulation de vitesse. Les premiers essais seront conduits à vide, les moteurs étant découplés des axes mécaniques, afin de valider le comportement du système dans des conditions simplifiées. Dans un second temps, les expérimentations seront réalisées en charge, avec les moteurs couplés aux axes verticaux du pont élévateur, permettant ainsi d’évaluer les performances du système dans des conditions représentatives de son fonctionnement réel.

Voir aussi

Articles – Pont élévateur

Story – Pont élévateur

Articles – Prototypes

Intégration d’un écran OLED i2c dans le système de contrôle du pont élévateur basé sur Arduino Nano R4

Cliquer pour masquer

Contexte de l’intégration d’un écran OLED i2c avec Arduino Nano R4

L’article précédent présente l’intégration d’une carte Arduino Nano R4 au sein de l’architecture électronique du système de contrôle dédié à la régulation de vitesse de rotation des moteurs du pont élévateur du diorama de la Batcave. Cet article expose, dans un premier temps, les motivations ayant conduit au remplacement des circuits imprimés (PCB) de conversion fréquence–tension par une carte Arduino UNO. Dans un second temps, il analyse les raisons techniques justifiant l’évolution vers une carte Arduino Nano R4.

Au-delà de la correction de dysfonctionnements identifiés dans les versions antérieures, l’intégration d’une carte Arduino Nano R4 dans l’armoire électrique de contrôle du pont élévateur ouvre la voie à l’intégration de nouvelles fonctionnalités. Parmi celles-ci figure notamment la possibilité d’un affichage local des données de traitement, directement au plus près du système. Cet article se concentre ainsi sur la validation fonctionnelle de cette capacité d’affichage.

Choix technologique et implantation fonctionnelle

Pourquoi choisir un écran OLED i2c avec Arduino Nano R4

Comme indiqué précédemment, les motivations ayant conduit à l’utilisation d’une carte Arduino Nano R4 dans cette architecture sont détaillées dans un article antérieur.

L’écran OLED i2c, piloté par la carte Arduino Nano R4 intégrée à l’armoire électrique de commande, a pour vocation d’assurer un affichage local des données au plus près du système de contrôle et de régulation de la vitesse des moteurs. Il permet notamment de visualiser les valeurs mesurées des fréquences de rotation des quatre moteurs.

Ce dispositif répond à un double objectif. D’une part, il facilite les phases de mise au point de la chaîne matérielle et logicielle dédiée à l’acquisition des données. D’autre part, il permet de vérifier la bonne transmission ainsi que le traitement cohérent de ces informations jusqu’à la console de commande centralisée.

Contraintes d’intégration dans l’armoire électrique de contrôle

Le choix d’un écran de 1,3″ résulte d’un compromis entre l’encombrement physique et la capacité d’affichage requise. En effet, ses dimensions doivent rester compatibles avec une intégration sur la porte de l’armoire électrique de commande, au sein de laquelle est implantée la carte Arduino Nano R4.

Parallèlement, cet écran doit offrir une surface d’affichage suffisante pour permettre une visualisation exploitable des quatre valeurs de fréquences de rotation correspondant aux moteurs du système. À ce titre, sa définition de 128 × 64 pixels permet d’envisager un affichage simultané et lisible de l’ensemble de ces informations.

Conception mécanique réalisée à l’aide de FreeCAD

La conception mécanique de l’intégration de l’écran i2c OLED 1,3″ a été réalisé avec le logiciel FreeCAD.

Dans la mesure où le présent article est spécifiquement consacré à l’intégration électrique de l’écran OLED au sein du système de contrôle du pont élévateur du diorama de la Batcave, les aspects relatifs à la conception mécanique des deux armoires constituant le système de commande seront traités dans une publication ultérieure.

FreeCAD est un modeleur 3D paramétrique open-source.

Schéma de montage

Conception du schéma électronique sous KiCad

Le schéma électronique a été réalisé à l’aide de la suite logicielle KiCad.

La présentation détaillée du schéma complet du système électronique de commande du pont élévateur du diorama de la Batcave, dont les différentes feuilles sont illustrées dans la capture d’écran figurant en en-tête de ce paragraphe, fera l’objet d’un article dédié à venir.

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

Périmètre de l’étude et perspectives de validation globale

Le schéma présenté se concentre exclusivement sur l’intégration de l’écran OLED en interface i2c avec la carte Arduino Nano R4.

Un article ultérieur sera consacré à la validation complète de la chaîne d’acquisition et de traitement des données, depuis les capteurs jusqu’à la console de commande centralisée.

Mise en place du banc de test et simulation du signal moteur

Dans le cadre de ce test fonctionnel de l’affichage des valeurs de fréquences, une carte Arduino UNO a été utilisée pour générer un signal carré de fréquence fixe 512 Hz, simulant ainsi les signaux issus des capteurs optiques des plateformes motorisées.

Ce même signal a été transmis aux 4 broches de la carte Arduino Nano R4 dédiées aux mesures de la fréquence de rotation des moteurs. Ce qui justifie que la même valeur soit affichée sur l’écran pour les 4 fréquences.

Rôle des résistances pull-up dans la communication I²C

Ce schéma met en évidence la présence de deux résistances de 4,7 kΩ. Il s’agit de résistances de tirage, couramment appelées résistances de pull-up. Leur rôle est d’assurer un niveau logique haut stable (ici 5 V) sur les lignes de communication, notamment lorsque celles-ci ne sont pas activement pilotées par un dispositif du bus.

En effet, sur un bus comme l’I2C, les composants ne génèrent pas directement un niveau haut. Ils peuvent seulement tirer la ligne vers le bas (niveau 0). Sans résistance de pull-up, la ligne resterait alors dans un état indéterminé lorsqu’elle n’est pas sollicitée. Ces résistances agissent donc comme un rappel vers le niveau haut, garantissant un signal propre et exploitable pour tous les éléments connectés au bus.

Spécificités du câblage i2c avec Arduino Nano R4

La difficulté rencontrée lors de la mise au point de ce montage, pourtant en apparence simple, tient au fait que la version précédente, basée sur une carte Arduino UNO, ne nécessitait pas l’ajout de résistances de pull-up. Le raccordement direct des lignes SDA et SCK de l’écran à celles de l’Arduino suffisait alors pour obtenir un fonctionnement correct de l’affichage.

En revanche, lors du remplacement de la carte Arduino UNO par une NANO R4, l’écran est resté totalement inactif. Ce comportement s’explique par une différence de conception interne des broches SDA et SCK entre les deux cartes. Contrairement à l’UNO, la NANO R4 ne permet pas un fonctionnement fiable du bus I2C sans l’ajout explicite de résistances de pull-up externes.

Source : https://docs.arduino.cc/tutorials/nano-r4/user-manual/

Le code

#include <pwm.h>
#include <Adafruit_SH110X.h>

const int MaxReadNumber = 10;
const int MaxPulseNumber = 1;
const int pinIn[] = {2, 4, 7, 8};

int Freq[] = {0,0,0,0};
int Period[] = {0,0,0,0};

float FreqInFloat = 0.0;
float PeriodInFloat = 0.0;

// PWM Duty Cycle
int DUTY_CYCLE_READ = 0;
int DUTY_CYCLE_INIT = 0;
float DUTY_CYCLE_SET = 0.0;

const int PIN_DUTY_CYCLE = A7;

const int PIN_FREQ0 = 2;
const int PIN_FREQ1 = 4;
const int PIN_FREQ2 = 7;
const int PIN_FREQ3 = 8;

const int PWM_D5_PIN = 5;
const int PWM_D6_PIN = 6;
const int PWM_D9_PIN = 9;
const int PWM_D10_PIN = 10;

PwmOut PWM_D5(PWM_D5_PIN);
PwmOut PWM_D6(PWM_D6_PIN);
PwmOut PWM_D9(PWM_D9_PIN);
PwmOut PWM_D10(PWM_D10_PIN);

Adafruit_SH1106G display = Adafruit_SH1106G(128, 64, &Wire, -1);

void setup()
{
pinMode(PIN_FREQ0, INPUT);
pinMode(PIN_FREQ1, INPUT);
pinMode(PIN_FREQ2, INPUT);
pinMode(PIN_FREQ3, INPUT);

pinMode(PWM_D5_PIN, OUTPUT);
pinMode(PWM_D6_PIN, OUTPUT);
pinMode(PWM_D9_PIN, OUTPUT);
pinMode(PWM_D10_PIN, OUTPUT);

PWM_D5.begin(25000.0f, 0.0f);
PWM_D6.begin(25000.0f, 0.0f);
PWM_D9.begin(25000.0f, 0.0f);
PWM_D10.begin(25000.0f, 0.0f);

MotorFrequencySetUp();

Serial1.begin(9600);

display.begin(0x3c, true);
display.clearDisplay();
//display.drawRect(0, 0, 128, 64, 1);
display.setTextSize(1);
display.setTextColor(SH110X_WHITE);
display.setCursor(0, 0);
display.println("BATLab112 Project");
display.println("Lifter Bridge Control");
display.setCursor(0, 24);
display.println("Freq.1 = Hz");
display.setCursor(0, 34);
display.println("Freq.2 = Hz");
display.setCursor(0, 44);
display.println("Freq.3 = Hz");
display.setCursor(0, 54);
display.println("Freq.4 = Hz");
display.display();
delay(500);
}

void loop()
{
for(int i=0; i<4; i++)
{
Period[i] = ReadPeriod(pinIn[i]);
PeriodInFloat = Period[i] * 1.0;
if(PeriodInFloat!=0)
{
FreqInFloat = (1000000/PeriodInFloat);
}
else
{
FreqInFloat = 0;
}
Freq[i] = floor(FreqInFloat);
}
DisplayFrequency();
}

float ReadPeriod(int signal)
{
float SignalPeriod = 0;
int PulseCounter = 0;
int HighTime = 0;
int LowTime = 0;
while(PulseCounter < MaxPulseNumber)
{
while (HighTime == 0)
{
HighTime = pulseIn(signal,HIGH);
}
while (LowTime == 0)
{
LowTime = pulseIn(signal,LOW);
}
SignalPeriod = HighTime + LowTime;
PulseCounter++;
}
SignalPeriod = SignalPeriod / PulseCounter;
return SignalPeriod;
}

void DisplayFrequency()
{
display.setTextColor(SH110X_WHITE, SH110X_BLACK);
for(int i=0; i<4; i++)
{
if (Freq[i]>999)
{
Freq[i] = 999;
}
}
display.setCursor(53, 24);
display.println(Freq[0]);
display.setCursor(53, 34);
display.println(Freq[1]);
display.setCursor(53, 44);
display.println(Freq[2]);
display.setCursor(53, 54);
display.println(Freq[3]);
display.display();
}

Cet extrait du sketch implémenté sur une carte Arduino Nano R4 se concentre spécifiquement sur la gestion de l’affichage des fréquences de rotation des moteurs via un écran OLED utilisant une interface I2C.

La fonction setup() assure l’initialisation de l’affichage en définissant une trame graphique structurée. Celle-ci comprend notamment des lignes de titre ainsi que des libellés associés aux différentes mesures, sous la forme « Freq.x = … Hz », permettant de préparer un cadre de visualisation clair et stable pour l’utilisateur.

La fonction DisplayFrequency() est, quant à elle, dédiée à la mise à jour des valeurs numériques affichées. Son fonctionnement repose sur une logique séquentielle simple consistant à écrire, à des positions prédéfinies de l’écran, les fréquences correspondant aux différents canaux mesurés. Cette fonction est appelée à l’issue de la phase d’acquisition des signaux, réalisée par la fonction ReadPeriod(), ainsi qu’après le traitement permettant de convertir les périodes mesurées en fréquences.

Validation fonctionnelle et perspectives d’évolution du système de contrôle Arduino Nano R4

Le test fonctionnel relatif à l’affichage des fréquences de rotation des quatre moteurs du pont élévateur du diorama de la Batcave s’avère concluant. Les résultats obtenus permettent d’ores et déjà de valider la capacité de la carte Arduino Nano R4 à acquérir et mesurer de manière stable et précise les signaux issus des capteurs optiques des plateformes motorisées.

Des travaux complémentaires demeurent toutefois nécessaires. Dans un premier temps, il conviendra d’évaluer la précision des mesures en conditions dynamiques, c’est-à-dire en présence de variations de fréquence induites par les comportements mécaniques du pont élévateur.

Dans un second temps, lors de l’intégration du système électronique de régulation avec la structure électromécanique du pont, il sera nécessaire de valider la mise en œuvre complète de la boucle logicielle de régulation des vitesses, afin d’assurer un pilotage cohérent et robuste de l’ensemble du dispositif.

Voir aussi

Articles – Pont élévateur

Story – Pont élévateur

Articles – Prototypes

Story – Pont élévateur – 018

Categorie :

Légende :

Le remplacement de 4 convertisseurs fréquence/tension par un microcontrôleur Arduino UNO, qui aurait du être l’ultime évolution du système électronique de contrôle du pont élévateur n’était en fait qu’une évolution de transition …

La nouvelle version de l’armoire électrique de contrôle de la vitesse de rotation des moteurs du pont élévateur intègre à présent un microcontrôleur Arduino Nano R4.

Arduino Nano R4 : Optimisation de l’électronique embarquée du pont élévateur du projet BATLab112

Electronique du pont élévateur – Prototype Ep3

Cliquer pour masquer

Résumé

Cet article détaille l’optimisation de l’électronique embarquée de l’armoire électrique de contrôle du pont élévateur du projet BATLab112, intégrant un Arduino Nano R4. Cette évolution améliore la compacité de l’armoire électrique, la robustesse du câblage et la maintenabilité du système. Le Nano R4 permet également un pilotage plus précis des moteurs via des signaux PWM,…

Première publication :

Dernière mise à jour :

Temps de lecture :

7–10 minutes

Mots clés :

Migration Arduino Uno vers Nano R4 : évolution du système de contrôle du pont élévateur

Suite à la phase de prototypage précédente, consacrée à la validation du principe de mesure et de régulation des vitesses des quatre moteurs du pont élévateur, une nouvelle évolution technique a été engagée : le remplacement de la carte Arduino Uno utilisée pour l’acquisition des signaux par une carte Arduino Nano R4 montée sur une carte adaptateur avec borniers à vis.

Cette mise à jour s’inscrit dans une démarche d’amélioration continue visant à renforcer la fiabilité, la compacité et la maintenabilité de l’électronique de commande du pont élévateur du diorama de la Batcave dans le cadre du projet BATLab112.

Validation du prototype précédent : acquisition des signaux et régulation PWM des moteurs

Le prototype antérieur avait permis de démontrer qu’une seule carte Arduino pouvait avantageusement remplacer les modules de conversion fréquence/tension initialement envisagés. L’Arduino Uno assurait alors la lecture des quatre signaux issus des capteurs optiques, leur traitement, puis la transmission des informations vers la console de commande.

https://batlab112.fr/2025/11/28/electronique-du-pont-elevateur-prototype-ep2/

Si cette architecture s’est révélée fonctionnelle, elle présentait néanmoins certaines limites. D’une part, l’encombrement de la carte Arduino Uno constituait une contrainte notable au regard des dimensions internes de l’armoire électrique. D’autre part, cette solution n’apportait pas d’amélioration significative en matière de robustesse du câblage, point identifié comme critique lors des phases de validation précédentes, notamment avec l’utilisation de PCB dédiés à la conversion fréquence/tension.

Arduino Nano R4 : une solution compacte pour systèmes embarqués contraints

Miniaturisation et intégration optimisée dans l’armoire électrique

Le format Nano, même associé à une carte adaptateur avec borniers à vis, permet un gain de place significatif par rapport à une carte Arduino Uno. Cette réduction d’encombrement autorise une implantation verticale du module sur son support, optimisant ainsi l’organisation interne de l’armoire électrique.

Cette nouvelle configuration favorise une circulation plus rationnelle des câbles, désormais intégrés dans des chemins dédiés. Elle contribue également à améliorer le réalisme global du diorama, en rapprochant l’architecture de celle d’une installation industrielle réelle.

Connectique renforcée : bornier à vis et accessibilité des signaux pour maintenance

Fiabilité du câblage et robustesse des connexions

L’utilisation d’une carte adaptateur équipée de borniers à vis constitue une amélioration majeure en termes de fiabilité. Ces connecteurs offrent une meilleure tenue mécanique et réduisent les risques de faux contacts, en particulier dans un environnement soumis à des manipulations ou à des vibrations.

Cette évolution corrige les limites observées sur les précédents modules de conversion, dont la connectique était moins adaptée à une exploitation durable.

Accès simplifié et modularité pour tests et mises à jour

Le faible encombrement de l’Arduino Nano R4 et son mode de connexion à la carte adaptateur facilitent les opérations de maintenance. Il devient possible de retirer rapidement la carte pour effectuer des mises à jour du programme (sketch) ou réaliser des tests fonctionnels en toute sécurité.

Par ailleurs, le connecteur support du Nano R4 est doté d’une double rangée de broches, permettant l’utilisation de câbles de prototypage. Cette caractéristique autorise la réalisation de mesures de contrôle directement sur les entrées et sorties de la carte, sans démontage du système, ce qui constitue un atout important en phase de mise au point.

Communication et alimentation : exploitation du port USB-C et interfaces embarquées

Le connecteur USB-C de l’Arduino Nano R4 présente un double avantage. Il permet non seulement d’assurer l’alimentation électrique de la carte, mais également d’envisager une communication directe avec l’environnement de développement Arduino (IDE).

Cette double fonctionnalité simplifie les opérations de configuration, de diagnostic et de mise à jour logicielle, tout en limitant le nombre de connectiques nécessaires. Elle s’inscrit pleinement dans une logique de simplification et de rationalisation de l’architecture embarquée.

Nouvelle architecture de l’armoire électrique de contrôle : intégration et performance du système

Screenshot : Conception de l’armoire électrique de contrôle sur FreeCAD

Optimisation de l’architecture de l’armoire électrique grâce à l’Arduino Nano R4

Cette démarche d’amélioration s’étend également au PCB de raccordement interne de l’armoire électrique. Dans sa version précédente, celui-ci présentait des limites de conception, notamment une résistance mécanique insuffisante pour supporter les contraintes induites par les opérations de vissage et de dévissage des câbles au niveau des connecteurs. La nouvelle version corrige ces faiblesses en renforçant la robustesse mécanique de la carte, tout en intégrant des fonctionnalités supplémentaires. Elle inclut désormais une protection par fusibles de la distribution électrique issue de l’armoire, ainsi que des broches dédiées aux tests fonctionnels de transmission des signaux PWM.

Transmission directe des signaux PWM via RJ12 vers les modules de puissance L298N

Les capacités de l’Arduino Nano R4 permettent d’envisager une évolution fonctionnelle notable : la transmission directe, via un câble RJ12, des signaux PWM dédiés à la régulation de la vitesse de rotation de chacun des moteurs. Ces signaux sont acheminés vers des modules de puissance de type L298N, en charge du pilotage effectif des moteurs au sein de l’armoire de puissance.

Cette organisation contribue à simplifier la chaîne de commande, en réduisant les intermédiaires électroniques, tout en renforçant la cohérence entre les niveaux de contrôle et de puissance. Elle favorise également une meilleure lisibilité des flux fonctionnels au sein du système.

Intégration d’un écran OLED I2C pour supervision locale et diagnostic embarqué

Dans ce nouveau contexte, l’intégration d’un écran OLED local apparaît comme une évolution cohérente. Connecté via le bus i2c, cet équipement offre la possibilité d’afficher en temps réel l’état de fonctionnement du système au plus près de son implantation. Il constitue ainsi un outil précieux pour les opérations de supervision, de diagnostic et de maintenance, en fournissant un retour d’information direct et indépendant de la console principale.

Évolution logicielle du système embarqué : adaptation au Nano R4

Le changement de carte ne s’est pas limité à une évolution matérielle. Il s’est accompagné d’une refonte du script Arduino afin d’exploiter pleinement les capacités du Nano R4. Cette évolution logicielle vise à améliorer la précision des mesures, la qualité de la régulation et la robustesse globale du système de contrôle du pont élévateur.

Mesure précise des vitesses moteur : acquisition optimisée des signaux capteurs

Dans la version précédente reposant sur des convertisseurs fréquence/tension, les signaux issus des capteurs optiques présentaient des fréquences trop faibles pour permettre une mesure précise et fiable. Cette limitation impactait directement la qualité du retour d’information nécessaire à la régulation.

L’utilisation directe de l’Arduino Nano R4 permet désormais une lecture plus fine des quatre signaux des capteurs optiques. Grâce à une meilleure résolution temporelle et à une acquisition directe des impulsions, le système est capable de mesurer avec précision les variations de vitesse des moteurs.

Régulation PWM optimisée : amélioration du calcul du rapport cyclique

L’évolution logicielle a également porté sur l’optimisation de la régulation des moteurs. Le calcul du rapport cyclique des signaux PWM a été affiné afin d’assurer un pilotage plus précis de la vitesse de rotation.

L’intégration de la bibliothèque dédiée « pwm.h » facilite la gestion des signaux PWM en offrant des fonctions plus adaptées et plus performantes. Elle permet notamment de simplifier la génération des signaux tout en améliorant leur précision.

Conclusion : Arduino Nano R4, une évolution clé pour un pont élévateur miniature fiable et performant

Transition Arduino Uno vers Nano R4 : bilan des améliorations matérielles et fonctionnelles

Le passage de l’Arduino Uno au Nano R4 marque une étape significative dans le développement de l’électronique du pont élévateur. Plus compact, plus performant et mieux adapté aux contraintes d’intégration en environnement miniature, ce nouveau contrôleur contribue à une amélioration globale du système.

Au-delà du gain d’encombrement, cette évolution se traduit par une meilleure maîtrise des aspects techniques, notamment en matière de précision de mesure, de régulation des moteurs et de qualité du câblage. Elle participe également à l’amélioration de l’esthétique du dispositif, en permettant une intégration plus discrète et plus cohérente avec le réalisme recherché.

Projet BATLab112 : vers un système embarqué miniature inspiré des standards industriels

Cette évolution ne se limite pas à un simple remplacement de carte électronique. Elle illustre la maturation progressive du projet BATLab112, qui tend à dépasser le stade du prototype expérimental pour se rapprocher d’un système embarqué structuré, fiable et maintenable.

La conception du diorama technique s’inscrit ainsi dans une logique comparable à celle d’un projet industriel : prise en compte des contraintes d’intégration, fiabilisation des connexions, optimisation des performances et anticipation des besoins de maintenance. Le pont élévateur devient alors un véritable équipement miniature, dont le fonctionnement et l’architecture s’inspirent directement des standards de l’ingénierie embarquée.

Perspectives : intégration finale et tests en conditions réelles

La prochaine étape du projet consistera à intégrer l’armoire électrique de Contrôle avec cette nouvelle architecture électronique au sein du système électronique de commande du pont élévateur. Cette phase permettra de valider le comportement du système en conditions réelles d’exploitation.

Voir aussi

Articles – Pont élévateur

Story – Pont élévateur

Articles – Prototypes

Arduino et Diorama du projet BATLab112 : Les consoles de commande

Introduction

Les consoles de commande du projet BATLab112 constituent des modules techniques intégrés au diorama de la Batcave, destinés à centraliser les commandes manuelles et l’affichage des données liées aux équipements industriels miniatures présent dans le diorama de la Batcave. Leur fonctionnement repose en grande partie sur l’intégration de cartes microcontrolleur Arduino, choisi pour leur facilité de mise en œuvre, leur modularité et la disponibilité de nombreux modules compatibles.
L’objectif principal est d’obtenir des consoles fonctionnelles, capables d’afficher des informations en temps réel sur l’état des équipements industriels, d’émettre des signaux lumineux et d’interagir avec d’autres sous-systèmes du diorama.

Fonction et organisation générale des consoles

  • Chaque console est conçue comme un bloc autonome comprenant :
  • Deux cartes Arduino Mega 2560
  • Deux écrans TFT 2,8’’
  • Un pupitre de commandes manuelles composées de switches, boutons poussoirs, Leds …
  • Des modules électroniques complémentaires en fonction des besoins techniques d’équipement contrôlé tels que des modules électroniques L298N

Les consoles de commande sont directement connectées aux sorties des armoires de raccordement du poste électrique.

Choix des microcontrôleurs

Modules d’affichage

Le choix des microcontrôleurs destinés aux consoles de commande est directement lié au type de modules d’affichage retenus. Les consoles du projet BATLab112 utilisent des écrans TFT tactiles 2,8’’, équipés d’un lecteur de carte au format SIM, nécessitant un nombre important de broches pour gérer simultanément l’affichage graphique, la couche tactile et les fonctionnalités annexes intégrées au module.

Pour la première console, deux écrans sont utilisés afin d’afficher en temps réel l’ensemble des informations relatives à l’état du système industriel contrôlé. Cette organisation à double affichage permet de répartir clairement les données selon leur nature et leur utilité opérationnelle. Les écrans sont ainsi mobilisés pour présenter :

  • L’état des commandes manuelles, incluant l’activation des interrupteurs, des boutons et des sélecteurs.
  • L’historisation des commandes, permettant de visualiser la dernière action effectuée ou de suivre la séquence d’ordres exécutés.
  • Une représentation visuelle de l’équipement, offrant un retour graphique instantané sur la position ou l’état général du dispositif piloté.
  • L’état des capteurs de fin de course, utile pour vérifier la conformité des déplacements ou des rotations simulées.
  • Les mesures spécifiques à l’équipement, telles que la vitesse de déplacement ou de rotation, les modes de fonctionnement sélectionnés, ou encore les valeurs de consigne.

Microcontrolleurs

La phase de conception préliminaire de la première console de commande, destinée au pilotage de la plateforme rotative de la Batmobile, a conduit au choix d’une carte Arduino Mega 2560. Ce choix s’explique principalement par le nombre élevé de broches disponibles, permettant de répondre aux besoins de raccordement identifiés lors de ce premier développement. L’architecture retenue devait également anticiper l’évolution des consoles futures, notamment celles destinées à piloter des équipements mécaniques plus complexes. En effet, si la plateforme rotative repose sur le pilotage d’un seul moteur, le pont roulant nécessite deux moteurs, le pont élévateur quatre, et certains bras robotiques jusqu’à cinq.

L’Arduino Mega 2560 présente ainsi plusieurs avantages pour la mise en œuvre des éléments techniques suivants :

  • Raccordement simple et direct des écrans tactiles TFT 2,8’’, équipés d’un lecteur de carte au format SIM, nécessitant un grand nombre de broches numériques et analogiques pour la gestion simultanée de l’affichage, du tactile et des fonctions associées.
  • Connexion des éléments de commande manuelle, incluant LED, interrupteurs et boutons poussoirs, chacun demandant un adressage propre et suffisamment de broches d’entrées/sorties.
  • Gestion des signaux PWM, utilisés pour le pilotage des moteurs ou pour la modulation des effets lumineux, nécessitant la disponibilité de plusieurs sorties PWM dédiées.
  • Accès à un port de communication série (Rx/Tx), indispensable pour les échanges de données entre microcontrôleurs ou entre la console et d’autres modules du diorama.

L’ensemble de ces facteurs a confirmé la pertinence du choix de l’Arduino Mega pour assurer la robustesse, la modularité et l’évolutivité requises par la suite du projet BATLab112.

Intégration esthétique

L’intégration des deux modules Arduino Mega 2560, indispensables à chacune des consoles de commande pour assurer le pilotage des deux écrans TFT 2,8″, a exercé une influence déterminante sur la conception générale de ces interfaces. Bien que les microcontrôleurs demeurent relativement compacts, leur installation directe, équipée de leurs écrans respectifs, sur le panneau vertical frontal de la console aurait entraîné une augmentation notable des dimensions hors tout. Une telle configuration se serait révélée incompatible avec les contraintes spatiales strictes imposées par l’intégration de quatre consoles au sein du diorama.

Afin de concilier cohérence technique, lisibilité fonctionnelle et exigences esthétiques, le choix s’est porté sur une implantation verticale et déportée à l’arrière des modules Arduino. Cette solution intermédiaire a permis d’optimiser l’espace tout en préservant la silhouette des consoles, garantissant ainsi une intégration harmonieuse dans l’ensemble scénographique du projet BATLab112.

Conclusion

La réalisation des consoles de commande du projet BATLab112 met en lumière l’intérêt particulier de l’écosystème Arduino pour les projets de diorama intégrant des fonctionnalités mécaniques, lumineuses ou interactives. Dans un contexte où la miniaturisation, la fiabilité et la polyvalence sont essentielles, les microcontrôleurs Arduino se révèlent être des outils parfaitement adaptés. Leur rapidité de mise en oeuvre, leur compatibilité immédiate avec une vaste gamme de modules d’affichage, de commande ou de pilotage moteur, ainsi que la simplicité de leur programmation, en font une solution idéale pour orchestrer les multiples sous-systèmes qui animent un diorama technique.

L’intégration des Arduino dans les consoles de BATLab112 montre à quel point ces microcontrôleurs facilitent le développement progressif d’un projet créatif. Ils permettent d’ajouter, de tester ou de modifier rapidement des fonctions, sans revoir entièrement l’architecture existante. Cette capacité d’évolution est un atout décisif dans un diorama où chaque module — plateforme rotative, pont roulant, pont élévateur ou bras robotique — impose ses propres besoins électriques et mécaniques. Grâce à l’Arduino, ces exigences peuvent être prises en charge de manière cohérente, tout en restant accessibles à un maquettiste ou un concepteur ne disposant pas nécessairement d’un bagage spécialisé en électronique industrielle.

Voir aussi

La story de l’avancement des consoles de commande

Le suivi d’avancement des consoles de commande

Electronique du pont élévateur – Prototype Ep2

À la suite du premier article sur la version initiale de l’électronique du pont élévateur, celui-ci présente les principales évolutions techniques mises en œuvre.… Lire la suite →

Première publication :

Dernière mise à jour :

Temps de lecture :

3–5 minutes

Introduction

Le premier prototype du système électronique destiné à la commande des quatre moteurs du pont élévateur du diorama pédagogique de la Batcave a mis en évidence plusieurs dysfonctionnements. Ceux-ci résultent principalement d’un choix de composants inadapté lors de la phase de conception, notamment au regard des performances attendues du système. Plus précisément, le prototype a révélé les limites techniques des quatre convertisseurs fréquence-tension utilisés comme interface entre les plateformes moteurs et la console de commande.

Les moteurs fonctionnant à des fréquences inférieures à 500 Hz, les convertisseurs délivrent des tensions de sortie présentant des variations inférieures à 50 mV. L’acquisition, la transmission et le traitement de ces signaux de très faible amplitude induisent un taux d’incertitude trop élevé pour garantir un fonctionnement suffisamment fiable et prévenir les risques de blocage du pont élévateur.

Présentation générale

Evolution de la conception

L’objectif principal de ce nouveau prototype est de valider le principe des modifications proposées à la conception initiale. Celles-ci reposent notamment sur le remplacement des quatre modules de conversion fréquence-tension par une carte à microcontrôleur de type Arduino.

Un second objectif consiste à évaluer l’intégration d’un écran LCD I2C associé au microcontrôleur, permettant l’affichage local des vitesses de rotation des moteurs ainsi que leur traitement au plus près des plateformes. Cette amélioration, non envisagée dans la conception initiale, a émergé lors de l’utilisation de la plateforme TinkerCAD, au cours de la simulation du remplacement des modules de conversion par un Arduino.

Un troisième objectif vise à valider un nouveau mode d’échange d’informations entre l’armoire électrique d’acquisition des signaux issus des capteurs optiques et la console de commande. Le premier prototype reposait sur la transmission de quatre signaux analogiques correspondant aux tensions en sortie des convertisseurs. L’intégration d’un microcontrôleur dans l’armoire électrique permet désormais d’envisager une communication plus fiable via les ports série (Rx/Tx). Le traitement des signaux est ainsi déporté vers ce microcontrôleur, libérant celui de la console de commande, qui est alors exclusivement dédié à la mise à jour de l’affichage sur l’écran TFT 2,8″.

Description générale du système

Comme indiqué dans la conclusion de l’analyse du premier prototype, l’architecture générale du système électronique a été globalement reconduite. Le dispositif comprend ainsi les quatre plateformes moteurs assurant l’entraînement des axes du pont élévateur, connectées à deux armoires électriques distinctes :

  • une armoire [1] dédiée à l’acquisition et au traitement des signaux en fréquence issus des capteurs optiques des plateformes ;
  • une armoire [2] destinée à la commande du sens et de la vitesse de rotation des moteurs.

Dans le cadre de ce nouveau prototype, un microcontrôleur Arduino UNO R3, déjà disponible dans le stock du projet BATLab112, a été retenu pour remplacer les quatre modules de conversion. Ce choix, fondé sur une démarche de rationalisation des coûts, demeure provisoire et pourra évoluer au cours des phases ultérieures du projet.

Implantation des nouveaux éléments

  • Le microcontrôleur Arduino Uno est installé à plat devant les armoires électriques.
  • L’écran LCD i2C est positionné de face, à proximité.
  • La liaison de transmission série entre les microcontrôleurs est assurée par le câble bleu et blanc.
  • Les quatre câbles transmettant les signaux en tension des convertisseurs vers la console de commande ont été supprimés : l’Arduino Uno est désormais connecté, via l’armoire n°1, directement aux sorties des capteurs optiques des plateformes moteurs.
  • Le câble transmettant la commande de vitesse entre la console et l’armoire n°2 a été retiré. L’Arduino Uno fournit désormais quatre signaux à rapport cyclique réglable, permettant de piloter indépendamment la vitesse de rotation de chaque moteur.

Conclusions

La conclusion de l’article consacré au premier prototype soulignait deux axes principaux d’amélioration :

  • Le remplacement des convertisseurs fréquence-tension par un microcontrôleur Arduino
  • L’amélioration de l’esthétique et de la robustesse des PCB des borniers des armoires électriques.

Le présent travail confirme la validité du principe de remplacement des convertisseurs par un microcontrôleur. Il reste toutefois à déterminer le modèle Arduino le plus adapté pour une intégration définitive au sein de l’armoire électrique d’acquisition et de traitement des signaux issus des capteurs optiques des plateformes moteurs. Un premier état des lieux indique que l’usage de modules Arduino Nano serait pertinent, leurs dimensions et caractéristiques répondant aux contraintes d’intégration et de performance. Leur déploiement sera effectué lors de la révision de l’implantation interne des armoires électriques.

Enfin, la refonte des PCB des borniers des deux armoires électriques sera également réalisée au cours de cette même phase de réaménagement interne.trique sera aussi mise en oeuvre lors de la reprise de l’implantation interne de ces deux armoires.

Voir aussi

Articles – Pont élévateur

Story – Pont élévateur

Articles – Prototypes

Story – Pont élévateur – 017

Categorie :

Légende :

L’ultime évolution du système électronique de commande des moteurs du pont élévateur du diorama de la Batcave est en cours de mise au point.

Le remplacement de 4 convertisseurs fréquence/tension par un microcontrôleur Arduino UNO pour le traitement des signaux issus des capteurs optiques des plateformes moteurs et la transmission de données vers la console de commande.

Pont élévateur – Electronique – Conception Ep2

Suite à la réalisation du premier prototype opérationnel, cet article présente la reprise de la conception de l’électronique de commande du pont élévateur, du diorama de la Batcave du projet BATLab112.


Introduction

Cet article fait suite à la conception détaillée de l’électronique de commande et la réalisation d’un premier prototype opérationnel de l’électronique de commande du pont élévateur du diorama pédagogique à l’échelle 1/12 de la Batcave du projet BATLab112.

Modification de la conception initiale

Les essais effectués à l’aide du montage prototype ont mis en évidence que les modules de conversion des signaux de fréquence, issus des capteurs optiques des plateformes moteurs, en signaux de tension exploitables par la carte Arduino Mega intégrée à la console de commande du pont élévateur, ne sont pas adaptés. En effet, la conversion de signaux de fréquence trop faibles génère des tensions dont les variations en amplitude, corrélées à la fréquence, sont insuffisantes pour permettre une interprétation fiable et précise par le microcontrôleur.

L’objet de cet article est double. Il s’agit, dans un premier temps, de proposer une nouvelle conception de l’électronique de commande, en remplaçant les modules de conversion fréquence/tension par des cartes Arduino, capables d’assurer directement la lecture, le traitement et la transmission des signaux issus des capteurs optiques.
Dans un second temps, l’objectif est d’introduire plusieurs améliorations fonctionnelles absentes de la première version du système, notamment la mise en place d’une régulation de vitesse pour chacun des quatre moteurs assurant l’entraînement des axes du pont élévateur. Cette évolution vise à garantir un mouvement synchronisé et sécurisé de l’ensemble des plateformes, tout en offrant une meilleure stabilité et une précision accrue lors des phases de montée et de descente.

Les éléments conservés depuis la version initiale

Dans une volonté de minimiser l’impact des modifications envisagées, tant en termes de temps que de coût, certains éléments existants doivent être conservés. Cette approche vise à réutiliser au maximum les composants et sous-ensembles déjà en place, afin de limiter les interventions matérielles et de garantir la compatibilité avec l’infrastructure électrique actuelle du projet.

Les armoires électriques

L’implantation de cette électronique au sein des deux armoires électriques est conservée. Les dimensions mécaniques de ces armoires demeurent inchangées, afin de maintenir la cohérence avec les autres ensembles électriques similaires du projet.

La conception de l’agencement de l’armoire dédiée au contrôle de la vitesse et du sens de rotation des moteurs n’est que marginalement affectée par le changement de procédé de mesure de la vitesse. Cependant, l’analyse du fonctionnement du prototype a mis en évidence la nécessité d’une évolution majeure : le système doit désormais permettre de piloter la vitesse de rotation de chacun des moteurs de manière indépendante. Cette modification ouvre la voie à une régulation plus fine du mouvement de chaque axe du pont élévateur, garantissant un meilleur équilibrage et une synchronisation plus précise de l’ensemble.

Dans le montage initial, le signal issu du générateur à rapport cyclique variable, conçu à partir d’un oscillateur NE555, produit un signal carré unique distribué simultanément vers les quatre entrées des deux doubles ponts en H assurant le pilotage des moteurs.
Cependant, ce dispositif, entièrement autonome et dépourvu de rétroaction, ne permet aucune régulation dynamique du rapport cyclique en fonction des variations de vitesse propres à chacun des moteurs. En conséquence, toute fluctuation mécanique ou électrique affectant un moteur se répercute sur l’équilibre global du système, sans possibilité de correction différenciée.

Schéma électronique

La reprise de cette conception électronique a également constitué l’occasion d’utiliser, pour la première fois dans l’avancement du projet BATLab112, l’outil en ligne TinkerCAD, dédié à la conception et à la simulation de circuits électroniques. Cet environnement virtuel a permis de modéliser les nouveaux schémas de commande avant leur réalisation concrète, facilitant ainsi les phases de test, de validation et d’ajustement.
L’usage de TinkerCAD a également contribué à limiter les erreurs de conception, qui se sont déjà avérées coûteuses en temps et en ressources matérielles, en permettant d’anticiper les incompatibilités potentielles entre composants et de valider les principes de fonctionnement avant toute phase de prototypage physique.

Pour accéder à TinkerCAD cliquer sur l’image ou sur ce lien : https://www.tinkercad.com/things/4NAy7qcVIJG

Présentation générale

Au centre de ce schéma, les deux cartes Arduino Uno jouent un rôle de représentation :

  • celle située à gauche symbolise la carte Arduino Mega 2650 utilisée dans la console de commande ;
  • celle située à droite correspond à la nouvelle carte Arduino intégrée au montage, dédiée à l’acquisition et au traitement des signaux électriques provenant des capteurs optiques de mesure des vitesses de rotation des moteurs.

Dans cette simulation, l’écran TFT 2,8″ associé à la carte Mega a dû être remplacé par un écran LCD I2C 16×2, en raison des limitations de la bibliothèque de composants disponibles dans TinkerCAD. Toutefois, ce remplacement s’est révélé être une opportunité technique : il a permis d’envisager une solution d’affichage local, directement au plus près des armoires de raccordement électriques.
Les faibles dimensions et la simplicité de câblage de ces écrans LCD offrent de nouvelles perspectives d’intégration, notamment sur la porte même des armoires électriques.

La platine de prototypage électronique présente sur le schéma remplit quant à elle un rôle symbolique, représentant la console de commande physique du dispositif.

Enfin, les quatre générateurs de fonctions simulent les signaux issus des capteurs optiques placés sur les plateformes moteurs. Ces générateurs, réglables individuellement, sont associés à quatre oscillogrammes permettant d’observer les rapports cycliques et les signaux de commande de vitesse de rotation produits par la carte Arduino.
Cette configuration a notamment permis de valider expérimentalement la régulation de vitesse des moteurs dans un environnement virtuel.

Évolution depuis la version initiale

Mesure de la vitesse de rotation des moteurs

La mesure de la vitesse de rotation des moteurs est la fonction la plus impactée par les évolutions de cette nouvelle conception. Jusqu’à présent, cette mesure était assurée par des modules de conversion fréquence/tension, qui se sont révélés inadaptés aux conditions réelles de fonctionnement et aux niveaux de signaux fournis par les capteurs.

Comme évoqué précédemment, l’objectif consiste à remplacer ces modules par une ou plusieurs cartes Arduino, chargées d’assurer l’acquisition, le traitement et la conversion des signaux de fréquence issus des capteurs optiques positionnés sur les quatre plateformes moteurs.


L’utilisation de l’outil de simulation TinkerCAD joue ici un rôle essentiel : elle permet d’expérimenter différentes configurations pour déterminer le nombre de cartes Arduino nécessaires à la gestion simultanée des signaux, ainsi que le modèle le plus approprié. Ce choix dépendra à la fois des capacités d’entrée/sortie disponibles et des contraintes d’encombrement mécanique, afin de garantir une intégration optimale en remplacement direct des anciens modules de conversion.

Edition des schémas électroniques

La simulation du montage électronique du diorama de la Batcave du projet BATLab112 est éditée avec l’application Web TinkerCAD.

Script Arduino

Script d’acquisition et traitement des signaux de vitesse moteur

/**************************************************************/
/* Script for Arduino Check Measure */
/* Measures and converts the frequency values from the */
/* generators to transmit them to the second Arduino */
/**************************************************************/
#include <LiquidCrystal_I2C.h>

#define COUNTER 1 // Nb pulses/measure
#define DUTY_CYCLE_INIT 70 // Initialization Duty Cycle

LiquidCrystal_I2C lcd_1(38, 16, 2);

/* GLOBAL VARIABLES *******************************************/
int PulseCounter = 1;
int Freq_min;
int Motor_min;

float Period[]={0,0,0,0};
float old_Period[]={0,0,0,0};

float Freq[]={0,0,0,0};
int Freq_int[]={0,0,0,0};
char Freq_char[4][4]={"000","000","000","000"};

int Duty_cycle[4]={DUTY_CYCLE_INIT,DUTY_CYCLE_INIT,DUTY_CYCLE_INIT,DUTY_CYCLE_INIT};
float Duty_cycle_control[4]={1,1,1,1};

const byte pinIn[] = {4, 7, 12, 13}; // Pins used to get Freq
const byte pinPWM[] = {3, 9, 10, 11}; // Pins PWM

/**************************************************************/
/* Void setup() */
/**************************************************************/
void setup()
{
/* ARDUINO PINOUT *******************************************/
//MANUAL COMMAND PIN
int PIN_FREQ0 = 4;
int PIN_FREQ1 = 7;
int PIN_FREQ2 = 12;
int PIN_FREQ3 = 13;

pinMode(PIN_FREQ0, INPUT);
pinMode(PIN_FREQ1, INPUT);
pinMode(PIN_FREQ2, INPUT);
pinMode(PIN_FREQ3, INPUT);

//PWM PINS
int PIN_PWM0 = 3;
int PIN_PWM1 = 9;
int PIN_PWM2 =10;
int PIN_PWM3 =11;

pinMode(PIN_PWM0, OUTPUT);
pinMode(PIN_PWM1, OUTPUT);
pinMode(PIN_PWM2, OUTPUT);
pinMode(PIN_PWM3, OUTPUT);


/* SET PWM FREQUENCY DIVISOR ********************************/
// PWM PIN 9 & 10 → 31372.55 Hz
//TCCR1B &= 0b11111000;
//TCCR1B |= 0b00000001;
// PWM PIN 3 & 11 → 31372.55 Hz
//TCCR2B &= 0b11111000;
//TCCR2B |= 0b00000001;

/* POWER PWM SIGNALS ****************************************/
analogWrite(PIN_PWM0, map(DUTY_CYCLE_INIT,0,100,0,255));
analogWrite(PIN_PWM1, map(DUTY_CYCLE_INIT,0,100,0,255));
analogWrite(PIN_PWM2, map(DUTY_CYCLE_INIT,0,100,0,255));
analogWrite(PIN_PWM3, map(DUTY_CYCLE_INIT,0,100,0,255));

/* INIT SERIAL1 PORT ****************************************/
Serial.begin(9600);

/* LCD FIRST DISPLAY ****************************************/
lcd_1.init();
lcd_1.backlight();
lcd_1.setCursor(0,0);
lcd_1.print("MEASURE");
lcd_1.setCursor(0,1);
lcd_1.print("WIP...");

delay(3000);
}

/**************************************************************/
/* Void loop() */
/**************************************************************/
void loop() {

/* CHECK FREQUENCIES ****************************************/
for(int i=0; i<4; i++)
{
Period[i] = ReadPeriod(pinIn[i]); // Period in µsec
Freq[i] = (1000000/Period[i]); // Frequency in Hz
}

/* DUTY_CYCLE CONTROL VALUE *********************************/
Freq_min = min(min(min(Freq[0],Freq[1]),Freq[2]),Freq[3]);
for(int i=0; i<4; i++)
{
if(Freq_min == Freq[i])
{
Motor_min = i;
}
}
for(int i=0; i<4; i++)
{
Duty_cycle_control[i] = Freq_min/Freq[i];
Duty_cycle[i] = Duty_cycle[i] * Duty_cycle_control[i];
analogWrite(pinPWM[i], map(Duty_cycle[i],0,100,0,255));
}

/* FORMAT FREQ VALUE ON 3 DIGITS ****************************/
// Freq value range : 10 Hz -> 500 Hz
for (int i=0;i<4;i++)
{
/*if (Freq[i]==0)
{
for(int c=0;c<3;c++)
{
Freq_char[i][c]="0";
}
}*/
if (Freq[i]<10)
{
Freq[i] = Freq[i] + 910;
}
if (Freq[i]<100)
{
Freq[i] = Freq[i] + 900;
}

/* CONVERTING (FLOAT) FREQ VALUE in CHAR ******************/
if(Freq[i]!=0)
{
Freq_int[i] = round(Freq[i]);
itoa(Freq_int[i],Freq_char[i],10);
}
}

/* SEND FREQ_CHAR VIA RxTx PORT *****************************/
for(int i=0; i<4; i++)
{
Serial.write(Freq_char[i],3);
}

/* DISPLAY VALUES *******************************************/
// FIRST : FREQUENCIES
lcd_1.init();
lcd_1.setCursor(0,0);
lcd_1.print("F0:");
lcd_1.print(Freq_char[0]);
lcd_1.setCursor(0,1);
lcd_1.print("F1:");
lcd_1.print(Freq_char[1]);
lcd_1.setCursor(9,0);
lcd_1.print("F2:");
lcd_1.print(Freq_char[2]);
lcd_1.setCursor(9,1);
lcd_1.print("F3:");
lcd_1.print(Freq_char[3]);

delay(3000);

// SECOND : DUTY CYCLE
lcd_1.init();
lcd_1.setCursor(0,0);
lcd_1.print("D0:");
lcd_1.print(Duty_cycle[0]);
lcd_1.setCursor(0,1);
lcd_1.print("D1:");
lcd_1.print(Duty_cycle[1]);
lcd_1.setCursor(9,0);
lcd_1.print("D2:");
lcd_1.print(Duty_cycle[2]);
lcd_1.setCursor(9,1);
lcd_1.print("D3:");
lcd_1.print(Duty_cycle[3]);

PulseCounter = 0;
delay(2000);
}

/**************************************************************/
/* Function : ReadPeriod() */
/* Input : The signal number of the measured period */
/* Return : none */
/* Digest : Use the Arduino pulseIn command to measure */
/* the signal period in microseconds */
/**************************************************************/
float ReadPeriod(int signal)
{
int pin = 0;
float VarPeriod = 0;
PulseCounter = 0;
while(PulseCounter <= COUNTER)
{
VarPeriod = (VarPeriod + pulseIn(signal,HIGH));
VarPeriod = (VarPeriod + pulseIn(signal,LOW));
PulseCounter++;
}
VarPeriod = VarPeriod / PulseCounter;
return VarPeriod;
}

Limite de fonctionnement du script

Régulation de la vitesse de rotation des moteurs

Le modèle de la bibliothèque TinkerCAD de moteur à courant continu équipé d’un encodeur ne permet, à priori, pas de simuler le fonctionnement réel de l’encodeur. Cette limitation a directement conduit à adopter une approche simplifiée pour la régulation de la vitesse des moteurs. En l’absence de signaux de retour exploitables, la régulation du rapport cyclique du signal PWM de pilotage reste très rudimentaire dans cette première version du script.

À partir d’une configuration initiale des rapports cycliques fixée à 70 % :

#define DUTY_CYCLE_INIT 70

La plus petite valeur parmi les quatre vitesses de rotation simulées est utilisée comme référence pour ajuster les rapports cycliques des trois autres moteurs. Cette méthode, bien que cohérente dans le cadre des contraintes de la simulation, ne constitue pas une véritable régulation en boucle fermée : elle repose uniquement sur une logique de comparaison relative, sans mesure réelle de la vitesse issue d’un encodeur.

De plus, les délais d’exécution du code et les latences propres à l’environnement de simulation TinkerCAD limitent la précision des ajustements et induisent un comportement parfois irrégulier. Ces approximations rendent difficile toute extrapolation directe du fonctionnement simulé vers un système physique réel.

Ainsi, le script doit être considéré avant tout comme une première approche conceptuelle de la régulation multi-moteurs. Il permet de valider les principes d’organisation du code — gestion des signaux PWM, comparaison des vitesses, et synchronisation relative — tout en offrant une base solide pour une future version du programme. 

Fréquences des signaux PWM

/* SET PWM FREQUENCY DIVISOR ********************************/
// PWM PIN 9 & 10 → 31372.55 Hz
// TCCR1B &= 0b11111000;
// TCCR1B |= 0b00000001;
// PWM PIN 3 & 11 → 31372.55 Hz
// TCCR2B &= 0b11111000;
// TCCR2B |= 0b00000001;

Ces lignes de script déclarées en commentaire correspondent à la mise en œuvre initiale de diviseurs de fréquence appliqués aux signaux PWM générés par les broches 3, 9, 10 et 11. L’objectif de cette modification était d’augmenter la fréquence de modulation, passant d’environ 490 Hz à des valeurs supérieures à 20 kHz, afin de rendre les signaux inaudibles pour l’oreille humaine. Cette approche avait été envisagée pour améliorer le confort sonore du système lors des phases de commande moteur. Cependant, elle a été finalement mise de côté, car l’augmentation de la fréquence PWM provoquait des dysfonctionnements dans la communication I2C utilisée par l’écran LCD, rendant son affichage inopérant.
Une solution alternative, consistant à utiliser des bibliothèques spécialisées telles que PWM.h, sera étudiée ultérieurement afin d’obtenir un contrôle plus fin des fréquences de modulation sans interférer avec les autres périphériques du système.

Bienfaits des limites de TinkerCAD

Les limites rencontrées lors de l’utilisation de TinkerCAD apparaissent clairement dès la conception du schéma électronique, notamment en raison de l’absence de certains composants essentiels utilisés dans le cadre du projet BATLab112, tels que la carte Arduino Mega 2560 ou encore les écrans TFT 2,8″.

Cependant, loin de constituer un frein, ces contraintes se sont révélées particulièrement formatrices. Elles ont favorisé une approche plus inventive et une optimisation du travail de conception. En effet, cette première expérience d’utilisation de TinkerCAD a permis de démontrer qu’une seule carte Arduino Uno pouvait remplacer les quatre modules de conversion fréquence/tension initiaux, tout en assurant l’acquisition et le traitement des signaux issus des capteurs.

L’absence de certains composants dans l’environnement de simulation a également encouragé la recherche de solutions alternatives et l’amélioration des montages existants. Ainsi, la nécessité d’optimiser l’utilisation des broches disponibles sur l’Arduino Uno, en nombre plus limité que sur la Mega 2560, a conduit au développement de nouvelles stratégies de communication.
Parmi celles-ci, la mise en place d’un échange de données par liaison série entre l’Arduino dédié à l’acquisition et au traitement des signaux de vitesse de rotation des moteurs, et l’Arduino de la console de commande responsable de l’affichage, constitue une évolution majeure. Cette approche a permis non seulement d’alléger le câblage, mais aussi d’améliorer la modularité et la clarté fonctionnelle du système.

Prototypage de validation

Maquette de prototypage

Cette maquette de prototypage est destinée à valider le câblage ainsi que le fonctionnement de la carte Arduino dédiée à l’acquisition, au traitement et à la transmission des signaux de vitesse des quatre moteurs. Elle constitue une étape préalable essentielle avant l’intégration du système complet sur le prototype fonctionnel.

Adaptations par rapport au montage TinkerCAD

Dans cette version matérielle, les générateurs de fréquences utilisés dans le montage TinkerCAD sont remplacés par un clone d’Arduino Mega, chargé de délivrer quatre signaux PWM. Deux de ces signaux sont associés à un diviseur de fréquence, permettant d’alterner entre deux valeurs de fréquences distinctes afin de simuler différentes vitesses de rotation des moteurs.

La carte Arduino Uno couplée à un écran LCD, représentant la console de commande dans la simulation TinkerCAD, est remplacée par la carte Arduino Mega équipée d’un écran TFT 2,8″. Cet ensemble est directement issu de la console de commande réelle du système.

De son côté, l’écran LCD initialement utilisé sur la carte Arduino Uno en charge de la mesure, du traitement et de la transmission des informations, est désormais remplacé par un écran OLED I2C, plus compact et offrant une intégration dans l’armoire électrique.

Conclusion

Le fonctionnement général de cette maquette est validé. Les échanges entre les cartes, ainsi que la génération et la lecture des signaux de vitesse, se comportent conformément aux attentes.
La prochaine étape consistera à intégrer ce montage dans les armoires électriques du prototype initial du système de commande, en liaison avec les plateformes moteurs, afin de procéder aux essais en conditions réelles.

Voir aussi

Articles – Pont élévateur

Articles – Conception détaillée