Sur un drone, les capteurs de navigation (centrale inertielle, magnétomètre, baromètre, GNSS) gagnent souvent à être éloignés du contrôleur de vol : loin des courants des moteurs, au calme vibratoire, sur un mât pour le GNSS. Les relier par un bus CAN plutôt que par des liaisons I²C ou UART change la donne. Voici les principes d'architecture d'un tel module, tels que nous les appliquons chez Kariboo.
Pourquoi le bus CAN
- Robustesse. La liaison différentielle résiste aux perturbations électromagnétiques d'un drone, là où un bus I²C de quelques dizaines de centimètres devient fragile.
- Un seul câble. Tous les nœuds partagent la même paire : ajouter un capteur ne demande pas de nouveau port sur le contrôleur.
- Des priorités matérielles. L'arbitrage du CAN garantit que la trame à l'identifiant le plus bas passe en premier. Les données les plus urgentes ne sont jamais retardées par un message de télémétrie.
- La détection d'erreurs. CRC, acquittement et retransmission automatique sont gérés par le contrôleur CAN, sans code applicatif.
Architecture matérielle
Le module repose sur un microcontrôleur STM32 doté d'un contrôleur CAN, entouré d'une IMU 6 axes, d'un magnétomètre 3 axes, d'un baromètre et d'un récepteur GNSS u-blox. Deux points méritent l'attention :
- L'horodatage. La sortie PPS du récepteur GNSS arrive sur une entrée de capture d'un timer. Chaque échantillon est daté dans une base de temps alignée sur le GPS, ce qui rend la fusion des données exploitable côté contrôleur.
- Les interruptions data-ready. Chaque capteur signale lui-même qu'une mesure est prête : pas de scrutation, une latence minimale et un échantillonnage régulier.
Le protocole : un identifiant par type de donnée
En CAN classique, une trame transporte 8 octets. Le principe de base consiste à attribuer un identifiant à chaque type de donnée, par ordre de priorité, et à transmettre des entiers mis à l'échelle plutôt que des flottants :
// ID 0x100 : accélération IMU, 1 LSB = 1 mg
typedef struct __attribute__((packed)) {
int16_t ax, ay, az;
uint8_t seq; // compteur de séquence : détecte les pertes
uint8_t flags; // saturation, capteur en défaut...
} can_imu_accel_t;
_Static_assert(sizeof(can_imu_accel_t) == 8, "trame CAN classique");Le compteur de séquence permet au récepteur de détecter une trame perdue, et l'assertion à la compilation garantit que la structure tient dans une trame. Les protocoles standardisés comme DroneCAN reposent sur les mêmes idées, avec en plus la segmentation des messages longs et la découverte automatique des nœuds.
Dimensionner la charge du bus
À 1 Mbit/s, une trame de 8 octets à identifiant standard occupe environ 111 bits, jusqu'à 135 bits avec le bit-stuffing dans le pire cas, soit environ 135 µs. Une IMU à 1 kHz qui publie accélération et gyroscope envoie deux trames par milliseconde : 270 µs par milliseconde, donc 27 % de charge. En ajoutant le magnétomètre à 100 Hz, le baromètre à 50 Hz et le GNSS à 10 Hz, on reste autour de 30 %.
Gardez la charge sous 50 % pour préserver la latence des trames moins prioritaires. Au-delà, passez au CAN FD, avec jusqu'à 64 octets par trame et une phase de données plus rapide.
Organisation du firmware sous FreeRTOS
- Une tâche par capteur, réveillée par l'interruption data-ready du composant. L'ISR ne fait que notifier la tâche, sans lecture SPI ni I²C.
- Les tâches capteurs déposent leurs trames dans une file unique, consommée par une tâche d'émission CAN.
- Les mailboxes matérielles du contrôleur CAN sont servies par ordre d'identifiant, pour que la priorité définie dans le protocole soit respectée jusque dans le MCU.
- La récupération automatique après un état bus-off est activée : un nœud isolé par une rafale d'erreurs revient seul sur le bus.
DroneCAN ou protocole maison ?
DroneCAN offre le plug-and-play avec PX4 et ArduPilot : c'est le bon choix pour un module destiné à un autopilote du marché, et c'est celui que nous avons fait pour notre module GPS Pro. Un protocole maison se justifie quand vous maîtrisez les deux extrémités du bus et que vous avez besoin de cadences, d'un horodatage ou de formats que DroneCAN ne prévoit pas, par exemple pour un système de mesure embarqué.
Vous concevez un drone ou un système embarqué qui a besoin de capteurs déportés ? Notre bureau d'études conçoit l'électronique et le firmware de bout en bout. Écrivez-nous à contact@kariboo.tech.