ESP32

Présentation

L’ESP32 est un microcontrôleur qui ressemble à un Arduino avec une radio greffée et les freins desserrés. Il a un processeur 32 bits double cœur qui tourne bien plus vite qu’un Uno, bien plus de mémoire, et — vedette — le Wi-Fi et Bluetooth intégrés. Cette combinaison explique sa domination en robotique loisir et IoT : un robot peut héberger une page web pour se commander, diffuser les données de capteurs vers votre téléphone, ou recevoir des ordres en Bluetooth, le tout depuis une puce bon marché.

Point crucial, on le programme avec le même IDE et langage Arduino déjà connus. L’apprentissage fait sur un Uno se transfère directement ; on gagne simplement connectivité et marge.

Fonctionnement

En son cœur, deux CPU Xtensa cadencés jusqu’à 240 MHz. Avoir deux cœurs compte pour les robots : un cœur peut exécuter votre boucle de commande avec une temporisation stable pendant que l’autre gère le Wi-Fi, pour que le réseau ne cale jamais les roues. Autour du CPU, les périphériques habituels — GPIO, canaux PWM, plusieurs CAN, I²C, SPI, UART — plus la radio.

Le fait pratique le plus important est la tension : l’ESP32 fonctionne en logique 3,3 V, pas en 5 V comme l’Uno. Ses broches ne sont pas tolérantes au 5 V. Une sortie capteur 5 V — comme la broche Echo d’un HC-SR04 — doit être abaissée à 3,3 V avant de toucher une broche ESP32, sous peine de dommage. Cette seule différence piège presque tous ceux venant d’un Uno.

Quand l’utiliser

Prenez un ESP32 quand votre robot doit être sans fil — télécommande, télémétrie, tableau de bord navigateur — ou quand il faut du calcul inaccessible à une carte 8 bits, comme traiter plus de capteurs ou exécuter une logique légère embarquée. La variante ESP32-CAM ajoute une caméra, ouvrant des projets simples de vision.

Restez avec un Arduino Uno quand vous apprenez les fondamentaux, quand la tolérance 5 V rend le câblage plus sûr, ou quand le projet est simple et hors ligne — entraîner quelques moteurs autour d’une ligne n’a pas besoin du Wi-Fi.

Câblage et pièges

• C’est du 3,3 V, et non tolérant au 5 V. Adaptez tout signal 5 V avant qu’il atteigne un GPIO. C’est la façon la plus fréquente d’endommager un ESP32 pour un débutant.
• Wi-Fi plus moteurs peuvent faire décrocher la carte. La radio tire des pics de courant vifs ; partager une alimentation faible avec des moteurs cause des resets. Alimentez les moteurs séparément via un pilote moteur et donnez à l’ESP32 un rail 3,3 V stable.
• Toutes les broches ne sont pas libres. Plusieurs GPIO sont en entrée seule, liés au comportement au démarrage, ou connectés à la flash interne. Vérifiez un brochage avant d’affecter les broches, sinon la carte ne démarrera pas.
• Bizarreries du CAN. L’un des deux CAN est indisponible pendant que le Wi-Fi est actif, et les lectures sont moins linéaires que celles d’un Uno — calibrez si la précision compte.

Les broches à ne pas utiliser

Un ESP32 a environ 34 GPIO et c’est vraiment trompeur, parce qu’un nombre significatif d’entre eux sont inutilisables, conditionnels, ou empêcheront le démarrage. Ce tableau vaut d’être lu avant tout câblage.

Les broches d’usage général les plus sûres sur une carte dev 30 broches standard sont GPIO 4, 5, 13, 14, 16, 17, 18, 19, 21, 22, 23, 25, 26, 27, 32, 33. Commencez là et vous éviterez tous les pièges ci-dessus.

Les broches de mode de démarrage sont l’échec le plus déroutant, parce que la carte fonctionne parfaitement jusqu’à ce qu’on branche quelque chose. Une résistance de rappel sur GPIO 12 — tout à fait raisonnable pour un bouton — signifie que la carte ne démarrera simplement pas, sans erreur ni sortie série.

Les broches en entrée seule piègent différemment : GPIO 34–39 n’ont ni rappel interne haut ni bas, donc un bouton sur l’une flotte et lit aléatoirement. Elles exigent une résistance externe.

3,3 V, et ce que cela coûte

Les broches de l’ESP32 ne sont pas tolérantes au 5 V, et c’est la façon la plus fréquente d’en endommager un. Tout signal 5 V exige un traitement :

L’asymétrie vaut d’être intériorisée : les sorties sont généralement sûres, les entrées généralement non. La broche Echo d’un HC-SR04 est le cas classique — elle sort un plein 5 V vers une broche prévue pour 3,6 V maximum absolu.

Le problème du CAN

Le CAN de l’ESP32 est le point faible de la puce, et faire semblant du contraire fait perdre des heures.

ADC2 ne fonctionne pas pendant que le Wi-Fi est actif. La radio l’utilise. Tout analogRead sur une broche ADC2 renvoie n’importe quoi ou bloque dès que le Wi-Fi se connecte — et puisqu’un robot sans fil est toute la raison d’utiliser un ESP32, cela écarte ADC2 presque entièrement. N’utilisez qu’ADC1 : GPIO 32–39.

La réponse n’est pas linéaire. Le CAN 12 bits est nettement non linéaire aux deux extrémités, et les lectures sous environ 0,1 V et au-dessus d’à peu près 3,1 V sont compressées. La puce a des données d’étalonnage usine que les fonctions esp_adc_cal de l’ESP-IDF appliquent pour vous ; l’analogRead Arduino ne les utilise pas par défaut.

S’il faut une vraie précision d’un capteur analogique, la réponse pragmatique est un CAN I²C externe tel qu’un ADS1115. Il coûte quelques dollars et supprime tout le problème.

L’alimenter sans décrochage

C’est là que les projets robots ESP32 échouent le plus souvent, et la cause n’est pas évidente.

La radio ne tire pas un courant stable — elle le tire en rafales. Une rafale d’émission peut faire 500 mA pendant quelques centaines de microsecondes contre 40–80 mA en moyenne. Une alimentation qui semble correcte au multimètre peut quand même s’affaisser sur ces pics, et l’ESP32 répond en redémarrant avec un message Brownout detector was triggered.

Ce dernier point mérite d’être dit plainement : injectez 5 V dans la broche VIN/5V et laissez le régulateur de la carte faire le 3,3 V. Injecter du 3,3 V directement contourne le régulateur et son filtrage, ce dont vous avez justement besoin.

Deux cœurs, et comment vraiment les utiliser

Le double cœur est le vrai avantage de l’ESP32 pour les robots, et le cadre Arduino le cache — votre loop() tourne sur le cœur 1, et la pile Wi-Fi sur le cœur 0.

Vous pouvez épingler une tâche à un cœur explicitement :

void controlLoop(void *param) {
  const TickType_t period = pdMS_TO_TICKS(10);   // exactly 100 Hz
  TickType_t last = xTaskGetTickCount();
  for (;;) {
    readSensors();
    updatePid();
    driveMotors();
    vTaskDelayUntil(&last, period);              // no drift, unlike delay()
  }
}

void setup() {
  xTaskCreatePinnedToCore(
    controlLoop, "control", 4096, nullptr,
    2,          // priority above the default
    nullptr,
    1);         // core 1 — leave core 0 for Wi-Fi
}

C’est le motif qui rend un ESP32 vraiment bon pour les robots plutôt que juste connecté : une boucle de commande à temporisation stricte sur un cœur, et un serveur web sur l’autre qui ne peut pas la caler. vTaskDelayUntil est le détail important — contrairement à delay(), il compense la durée du corps de boucle, pour que la période reste exactement 10 ms.

Dépannage

ESP32 ou Arduino Uno ?

Les deux utilisent le même langage et IDE, c’est l’intérêt — la transition ne coûte presque rien en code et pas mal en discipline de câblage.

La recommandation honnête : apprenez sur un Uno, construisez sur un ESP32. La tolérance 5 V de l’Uno et l’absence totale de pièges de broches rendent vos premières erreurs récupérables. Une fois la boucle de commande comprise et les masses communes acquises, l’ESP32 donne quinze fois la fréquence d’horloge, 260 fois la mémoire, et une radio, pour à peu près le même prix.

La variante ESP32-CAM mérite d’être connue à part : elle ajoute une caméra et un slot SD pour quelques dollars, et c’est de loin la voie la moins chère vers la vision robotique — au prix de presque plus aucun GPIO libre.