Fondements d'électronique robotique : un parcours d'apprentissage
Alimentez un robot qui tient sous charge, mettez plusieurs capteurs sur un bus I²C, et écrivez une boucle qui les lit tous sans jamais bloquer.
La plupart des problèmes robots qui ressemblent à des problèmes logiciels n’en sont pas. La carte redémarre et on accuse le code ; un capteur renvoie n’importe quoi et on accuse la bibliothèque ; le robot ignore son pare-chocs et on accuse la logique. Dans chaque cas, la faute est une couche plus bas, dans la partie du système dont personne n’a écrit de tutoriel parce qu’elle semblait trop basique pour en avoir besoin.
Ce parcours est cette couche. Il couvre l’alimentation — pourquoi la tension d’une batterie s’effondre quand les moteurs démarrent et quoi y faire ; le bus I²C — ce que font vraiment ces deux fils partagés par chaque capteur ; et la temporisation — pourquoi une boucle qui s’arrête pour attendre est un robot qui ne peut pas réagir.
Rien de tout cela n’est difficile. Tout est supposé par chaque autre parcours de ce site.
Avant de commencer
Il faut un microcontrôleur déjà programmable et la volonté de mettre un multimètre aux bornes d’une batterie. Pas de théorie de la commande, pas de maths au-delà de l’addition et d’une division. Si vous avez construit quoi que ce soit — même une LED clignotante — vous êtes prêt.
Ce que vous saurez faire
- Distinguer un redémarrage d’un plantage en moins d’une minute, et savoir lequel vous regardez avant d’ouvrir le moindre code.
- Additionner la consommation d’un robot et choisir un pack batterie d’après ce nombre, plutôt que d’après ce qui venait dans le kit.
- Expliquer pourquoi une pile 9 V à la plus haute tension de l’étagère donne le pire résultat sous charge, et prédire de combien s’affaissera tout pack.
- Câbler plusieurs capteurs sur un bus I²C, les trouver avec un scanner, et résoudre une collision d’adresses de trois façons différentes.
- Écrire une boucle qui lit des capteurs, pilote des moteurs et rend compte à trois rythmes différents sans jamais bloquer — avec la comparaison de dépassement correcte.
- Mesurer votre propre pire temps de boucle au lieu de le supposer.
Où l’on se heurte
Prendre « ça n’a pas redémarré » comme preuve que l’alimentation va bien. Le détecteur de sous-tension d’un Arduino est réglé à 2,7 V, mais un ATmega328P à 16 MHz exige environ 3,8 V pour être dans sa vitesse nominale. Dans cette bande, la puce tourne hors spécification sans que rien n’intervienne, et c’est là que vivent les fautes les plus étranges d’un robot — variables corrompues, servomoteur qui saute, capteur renvoyant un non-sens plausible.
Ajouter un condensateur en espérant qu’il corrige un redémarrage. L’arithmétique dit le contraire : un condensateur de 1000 µF chargé de porter une pointe de 2 A pendant 10 ms chuterait de 20 V. Il nettoie l’ondulation de commutation et les pics de commutation, ce qui vaut la peine, mais seule une batterie plus rigide porte la pointe.
Empiler des cartes d’extension sur un bus. Presque chaque carte est livrée avec ses propres résistances de rappel, et elles se mettent en parallèle. Trois cartes sont limites et la quatrième fait passer le bus sous le courant absorbable par tout périphérique — donc trois capteurs fonctionnent et le quatrième les tue tous, sans que rien soit réellement cassé.
Lire une adresse 8 bits dans une fiche technique. La fiche d’une MPU-6050 dit 0xD0 ; la bibliothèque Arduino
veut 0x68, les mêmes bits décalés d’un rang vers la droite. C’est l’erreur I²C la plus fréquente, et elle ressemble exactement à une carte morte.
Écrire now >= last + interval. Cela se lit plus naturellement que la forme par soustraction et cela
casse au dépassement des 49,7 jours, en déclenchant en continu au lieu d’attendre. Soustrayez toujours.
Accuser la logique de boucle pour une boucle bloquée. Les interruptions continuent de tourner pendant delay(), donc un
compte de codeur reste parfaitement exact pendant que le robot cesse de réagir — ce qui fait ressembler le symptôme
à un bogue de décision plutôt qu’à un bogue temporel.
Ce qu’il vous faut
| Quoi | Pourquoi ce parcours en a besoin | Coût approx. |
|---|---|---|
| Un microcontrôleur programmable | Chaque mesure ici est prise sur une carte en marche, pas sur papier | Arduino Uno, ~8 $ en clone |
| Un multimètre | Le seul instrument dont ce parcours ne peut se passer — chaque affirmation y est vérifiée par vous | ~15 $ |
| Un pack batterie sous charge | Un pack mesuré à vide ne dit rien ; il en faut un qui entraîne quelque chose | Porte-piles 4×AA ou Li-ion 2S |
| Deux cartes d’extension I²C | Une carte ne montre jamais le problème de rappels. Deux commencent à le montrer. | MPU-6050 + autre chose, ~5 $ |
| Un ou deux moteurs | La charge qui fait s’affaisser le rail — la faute que ce parcours existe pour expliquer | Tout moto-réducteur à courant continu |
Pas d’oscilloscope. Chaque mesure de ce parcours est en continu et faisable avec un multimètre bon marché.
Pourquoi le parcours suit cet ordre
L’ordre n’est pas arbitraire — chaque nœud retire une façon dont le suivant pourrait vous mentir.
La temporisation vient avant tout ce qui est mesuré. Une boucle bloquée rend toute autre mesure suspecte, car on ne peut plus dire quand une lecture a été prise. Une fois la boucle non bloquante, on peut croire un horodatage, et seulement alors une mesure vaut d’être notée.
L’alimentation vient avant l’analogique. analogRead sur Arduino est ratiométrique — elle rend
l’entrée comme une fraction de sa référence, et la référence par défaut est le même rail 5 V que les
moteurs tirent vers le bas. Mesurez une batterie via un diviseur sur un rail affaissé et la
lecture monte quand la batterie baisse. Lire honnêtement une tension est impossible avant de savoir
ce que fait votre rail, donc le nœud d’alimentation doit venir en premier.
L’I²C vient après l’alimentation mais est indépendant de l’analogique. Le bus est un sous-système séparé, qui échoue à sa façon — par arithmétique des rappels et collisions d’adresses, pas par affaissement d’alimentation. Il part directement du nœud de la carte, et c’est pourquoi l’arbre bifurque là.
Le laboratoire vient en dernier. Le simulateur de capteur permet d’ajouter bruit, biais et pertes à un signal propre délibérément. Ce n’est instructif qu’après avoir vu votre propre matériel les produire accidentellement et savoir ce qui a causé chacun.
Étapes : comment savoir qu’une étape est acquise
Chacune est un test d’établi, pas un quiz. Si vous ne pouvez pas produire le nombre, l’étape n’est pas faite.
| Étape | Le test | Ce à quoi ressemble la réussite |
|---|---|---|
| Temporisation non bloquante | Affichez la pire durée de votre boucle sur 10 secondes | Un nombre en microsecondes mesuré, pas supposé — qui ne grandit pas quand un capteur est débranché |
| Batterie sous charge | Mesurez la tension du pack moteurs coupés, puis bloqués | Vous pouvez énoncer l’affaissement en volts et le diviser par le courant pour obtenir la résistance interne du pack |
| Budget d’alimentation | Additionnez sur papier la consommation de chaque périphérique, puis mesurez le total | Papier et appareil concordent à environ 20 % près ; sinon, vous avez trouvé un périphérique tirant plus que sa fiche technique |
| Entrée analogique | Lisez la même batterie via votre diviseur moteurs coupés puis en marche | La lecture ne change pas quand les moteurs démarrent — si oui, votre référence bouge |
| Bus I²C | Lancez un scanner de bus en ajoutant chaque carte une à une | Chaque adresse apparaît, et vous pouvez nommer la résistance totale de rappel sur le bus |
| Collision d’adresses | Verrouillez la broche AD0 de la MPU-6050 au haut | Le scanner annonce 0x69 au lieu de 0x68 — et vous pouvez expliquer pourquoi la fiche dit 0xD0 |
Où ce parcours s’arrête
Ce parcours s’arrête délibérément au point où l’électronique cesse de vous mentir. Il ne couvre ni pilotes de moteurs, ni boucles de commande, ni rien qui décide où un robot devrait aller — ce sont les parcours commande des moteurs et commande PID, qui supposent tous deux tout ce qui précède.
Il s’arrête aussi avant trois choses à nommer pour que vous sachiez qu’elles existent. Il ne couvre pas les régulateurs à découpage, manière d’obtenir 5 V depuis un pack 12 V sans brûler la différence en chaleur dans un régulateur linéaire. Il ne couvre pas l’adaptation de niveaux entre périphériques 5 V et 3,3 V, nécessaire dès que vous mettez un ESP32 et un capteur 5 V sur le même bus. Et il ne couvre pas le routage de circuits imprimés ni la soudure — tout ici se fait sur platine d’essai, parfait pour apprendre et lui-même source de fautes intermittentes dès qu’un robot se met à bouger.
Parcours d'apprentissage
Le parcours
Suivez les nœuds dans l'ordre — chacun débloque le suivant une fois terminé. Votre progression est enregistrée sur cet appareil.
0 / 9 terminés
Questions courantes
Questions fréquentes
Quelle électronique faut-il connaître avant de construire un robot ?
Trois choses, dont aucune avancée. Il faut dimensionner une alimentation d'après le courant réellement tiré par votre robot, pour qu'il ne redémarre pas quand les moteurs démarrent. Il faut comprendre le bus I²C assez pour mettre plusieurs capteurs sur deux fils partagés sans qu'ils se battent. Et il faut écrire une boucle de commande qui ne s'arrête jamais pour attendre, pour que le robot réagisse pendant qu'il fait autre chose. Tout le reste — théorie de la commande, navigation, cinématique — repose sur ces trois-là.
Pourquoi mon Arduino redémarre-t-il quand les moteurs démarrent ?
La résistance interne de la batterie convertit l'appel de courant des moteurs en chute de tension, et tout le rail s'affaisse avec. Un moteur tirant une pointe de 2 A à travers un pack de 0,5 Ω de résistance interne tire le rail d'un volt entier avant tout régulateur. Si ce creux passe la carte sous son seuil de sous-tension, elle redémarre. La correction est une batterie plus rigide et une alimentation moteur séparée, pas un condensateur plus gros — un condensateur de 1000 µF chargé de porter 2 A pendant 10 ms chuterait de 20 V, donc il ne peut pas ponter une pointe de cette taille.
Combien de capteurs I²C puis-je mettre sur un Arduino ?
L'espace d'adressage permet 112 périphériques, mais la limite électrique arrive bien avant. Presque chaque carte d'extension porte ses propres résistances de rappel, typiquement 4,7 kΩ, et empiler des cartes les met en parallèle. Quatre cartes donnent environ 1,2 kΩ, ce qui sous 5 V exige plus de 4 mA de courant absorbé — au-delà des 3 mA qu'un périphérique I²C doit supporter. Trois cartes fonctionnent d'habitude et la quatrième tue tout le bus. Retirez les rappels de toutes les cartes sauf une et vous pouvez aller bien plus loin.
delay() est-il vraiment si mauvais dans le code robot ?
Pour un robot, oui. Pendant que le processeur reste dans delay(), il ne lit aucun capteur et ne prend aucune décision — un robot dans delay(500) est aveugle une demi-seconde, soit 15 cm de déplacement à 0,3 m/s. Ce qui rend le diagnostic difficile, c'est que les interruptions continuent de tourner, donc les comptes de codeurs restent parfaitement exacts pendant ce temps. Le symptôme ressemble à une logique de décision cassée plutôt qu'à un blocage temporel. Remplacez par le motif millis(), et soustrayez plutôt qu'additionner en comparant, sinon la comparaison casse au dépassement des 49,7 jours.
Faut-il un oscilloscope pour parcourir ce chemin ?
Non. Un multimètre suffit pour tout ici — mesurer la tension d'une batterie sous charge, vérifier la sortie d'un diviseur, confirmer qu'un rail ne s'est pas affaissé. Un oscilloscope rend les microcoupures et les problèmes I²C bien plus faciles à voir, et si vous en possédez un utilisez-le, mais chaque mesure demandée par ce parcours est en continu et faisable avec un appareil à 10 £.
Combien de temps ce parcours prend-il ?
Environ deux heures de lecture sur les quatre tutoriels, et en pratique une soirée ou deux à l'établi pour faire vraiment les mesures. Les mesures sont l'objet — les nombres que ce parcours apprend à croire sont l'affaissement de votre propre batterie, le total de rappels de votre propre bus, et le pire temps de votre propre boucle, dont aucun ne se cherche dans un tableau.