La quantisation post-entraînement (PTQ) échoue systématiquement sur les contrôleurs de moteur à courant continu sans capteur, tandis que la quantization-aware training (QAT) impose un cycle de développement incompatible avec les contraintes temps réel embarqué. Le choix entre ces deux méthodes ne relève pas de la théorie. Il dicte la stabilité de la boucle de courant, la latence d'inference et la viabilité de la supply chain.
Latence et précision : le dilemme du Cortex-M
Les MCU Cortex-M7/M33 tournent à 400-600 MHz. La bande passante mémoire et les unités vectorielles (NEON) limitent le throughput des couches de neurones. Une inference mal quantisée dégrade le rapport signal/bruit des capteurs de courant. Le drift s'accumule. Le contrôleur FOC oscille. La PTQ compresse les poids en int8 sans recalibrer les activations. C'est rapide. C'est dangereux pour le contrôle moteur.
La QAT intègre la quantification pendant l'entraînement. Le modèle apprend à compenser les erreurs d'arrondi. Le résultat est stable. Le coût est un cycle de training supplémentaire et une calibration fine. Sur un MCU, ce coût se paie en RAM et en temps de boot.
Post-Training Quantization (PTQ) : rapidité et limites
La PTQ calcule les bornes min/max des activations sur un jeu de calibration. Elle applique un scale uniforme ou par-tensor. L'inference devient un ensemble de mul-add int8. CMSIS-NN optimise ces kernels. Le déploiement est trivial.
Les limites sont matérielles. Les capteurs de courant shunt ont un offset de 2-5 mV. Les PWM introduisent du jitter. La PTQ ne modélise pas ces non-linéarités. Sur un BLDC, cela se traduit par un couple pulsatoire à 10% de la vitesse nominale. Le flux estimé diverge. L'observateur sensorless perd sa référence.
La PTQ reste viable pour le diagnostic de défauts (défaut de capteur, déséquilibre de phase). Elle échoue pour la commande active.
Quantization-Aware Training (QAT) : précision au prix du cycle
La QAT insère des nœuds de quantification/déquantification simulés dans le graphe TensorFlow. L'entraînement ajuste les poids pour minimiser l'erreur de quantisation. Le modèle exporté contient des scales fixes. L'inference sur MCU n'a plus besoin de calibration.
Le cycle de développement augmente de 30-40%. Il faut un jeu de données de calibration représentatif des régimes de fonctionnement. Il faut vérifier la convergence. Sur un STM32H7, la QAT réduit l'erreur de couple de 0.8% à 0.15% dans les tests en boucle fermée.
La QAT exige une gestion stricte de la mémoire. Les buffers d'activation doivent être alloués statiquement. Les alignements DMA (64 bytes) sont obligatoires pour éviter les bus errors. Le code suivant illustre la configuration du pool mémoire TFLite Micro :
// Allocation statique pour éviter la fragmentation RAM
constexpr int kTensorArenaSize = 32 * 1024; // 32 Ko pool CMSIS-NN
static uint8_t tensor_arena[kTensorArenaSize];
// Initialisation de l'interpréteur TFLite Micro
tflite::MicroInterpreter interpreter(model, resolver, tensor_arena, kTensorArenaSize);
interpreter.AllocateTensors();
// Vérification critique : l'erreur d'alignement DMA provoque un HardFault
if ((uintptr_t)tensor_arena % 64 != 0) {
// : ajuster l'alignement selon le datasheet STM32H7 RM0433
printf("DMA alignment error\n");
}
Intégration CMSIS-NN et TFLite Micro sur STM32
CMSIS-NN fournit les kernels arm_convolve_HWC_q7_RGB et arm_dense_layer_q7. Ils exploitent les instructions SIMD du Cortex-M7. L'intégration avec TFLite Micro nécessite de mapper les opérations du graphe vers ces kernels.
Le point de friction est le routage DMA. Le STM32H7 partage le bus AXI entre le CPU, le DMA et le FOC timer. Une inference CMSIS-NN active peut starver les interruptions de comparaison de courant. La solution consiste à désactiver le DMA pendant l'inference ou à utiliser le NPU dédié du STM32U5.
La latence d'inference pour un modèle de 15k paramètres sur Cortex-M7 atteint 1.2 ms avec CMSIS-NN. Sans optimisation, elle dépasse 4 ms. La boucle de courant à 20 kHz tolère 50 µs de jitter. L'optimisation n'est pas optionnelle.
Pipeline de déploiement : de TensorFlow Lite à l’MCU
Le pipeline suit quatre étapes. Export du modèle quantisé. Conversion en C-array. Intégration des kernels CMSIS-NN. Validation sur target.
La calibration QAT se fait en Python. Le script extrait les scales et les intègre dans le modèle TFLite. Le convertisseur tflite_convert génère le C-array. Les headers CMSIS-NN sont inclus. Le code d'inference est compilé avec -O3 -mcpu=cortex-m7 -mfpu=fpv5-sp-d16.
La validation sur target utilise un oscilloscope et un analyseur logique. On mesure le couple, la vitesse et la consommation. On compare avec le modèle float. L'écart doit rester <2% sur la plage de fonctionnement.
Alternatives européennes et souveraineté des composants
La stack TinyML repose majoritairement sur des IP ARM (Royaume-Uni) et des frameworks US (TensorFlow). La supply chain MCU est critique. Les ESP32-S3 dépendent d'Espressif (Chine). Les risques ITAR et les restrictions d'export affectent les projets industriels.
Les MCU STMicroelectronics (France) et NXP (Pays-Bas) offrent des alternatives validées. Le STM32H7 intègre un DSP et des unités vectorielles. Le STM32U5 ajoute un NPU 0.6 TOPS. Pour la stack logicielle, Micro-ROS et les travaux du CNRS-LAAS sur les frameworks de quantisation ouverts réduisent la dépendance aux outils US.
Le EU Chips Act finance la fabrication de MCU 28-40 nm en Europe. La souveraineté technologique passe par le choix de composants ITAR-free et l'adoption de stacks ouvertes. Le contrôle moteur embarqué ne peut ignorer cette réalité.
Recommandations pratiques pour la production
La PTQ convient au diagnostic. La QAT est obligatoire pour la commande active. Utilisez CMSIS-NN pour les kernels int8. Gérez le pool mémoire statiquement. Vérifiez les alignements DMA. Validez en boucle fermée.
Le cycle de développement augmente. La stabilité du moteur aussi. Le choix se justifie par la fiabilité. La supply chain se sécurise. La production suit.