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.
Pour plus d’infos :
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.
BATLab112 