Intégration BMS bus CAN : CAN vs SMBus vs DroneCAN dans la conception de pack

Réponse rapide : CAN, SMBus et DroneCAN résolvent le même problème (faire sortir la télémétrie de la batterie hors du pack) à trois points différents de la courbe complexité-capacité. SMBus est une liaison simple, à faible nombre de nœuds, généralement exploitée en mode maître unique pour une batterie dialoguant avec un hôte. CAN est un bus multi-maître, tolérant aux fortes perturbations électromagnétiques, conçu pour de nombreux nœuds sur une seule paire de fils. DroneCAN fonctionne sur la couche physique de CAN et ajoute un dictionnaire de messages standardisé ainsi qu'un adressage dynamique des nœuds que PX4 et ArduPilot parlent déjà nativement. Le choix se fait selon le nombre de nœuds, l'exposition aux perturbations électromagnétiques, et le fait que votre pile de vol ou de mouvement attende déjà DroneCAN, pas selon le protocole qui sonne le plus moderne.

Pourquoi le choix du protocole façonne toute l'intégration du pack

Le protocole de communication est l'une des dernières choses que les ingénieurs fixent lors de la spécification d'un pack de batteries sur mesure, et l'une des plus coûteuses à changer par la suite.

Le fixer trop tard fait mal tourner trois choses. D'abord la complexité de passerelle : si le BMS parle SMBus mais que le contrôleur de vol ne dispose que d'une interface CAN, quelqu'un doit construire et valider un pont protocolaire qui n'aurait pas eu besoin d'exister. Ensuite la télémétrie corrompue par les perturbations électromagnétiques : un bus conçu pour un banc de laboratoire calme se comporte différemment à côté de quatre ESC commutant à des dizaines de kilohertz, et cette différence se manifeste par des lectures de tension intermittentes, pas par une panne franche. Enfin des échecs de vérification d'armement avant vol : la plupart des piles d'autopilote refusent de s'armer sans données de batterie valides et à jour, si bien qu'une connexion de bus marginale se transforme en aéronef cloué au sol, pas en simple trou dans les journaux.

Rien de tout cela n'est une malchance spécifique au protocole. C'est la conséquence directe du fait de spécifier « une interface de communication » au lieu de spécifier CAN, SMBus ou DroneCAN avec la couche physique et le format de message décidés avant que la disposition du pack ne soit dessinée. Ce guide fournit le détail au niveau trame, couche physique et mode de défaillance pour prendre cette décision correctement et la spécifier d'une manière que votre fournisseur de BMS et votre équipe d'intégration puissent tous deux construire.

Les packs pour drones de Dan-Tech sont déjà livrés en standard avec CANBUS, RS485 et UART comme options de communication Smart BMS, et des variantes de connecteurs compatibles CAN et DroneCAN sont disponibles sur demande. Cet article explique ce qui se passe réellement sur le fil afin que vous puissiez spécifier le bon choix.

CAN, SMBus et DroneCAN comparés : les chiffres qui comptent

Les trois protocoles font circuler de petites charges utiles de télémétrie (tension, courant, température, état de charge) entre une batterie et un hôte. Ils diffèrent par la couche physique, l'adressage et la topologie, pas par les données transportées.

La ligne qui fait trébucher la plupart des premières spécifications est le nombre de nœuds. CAN lui-même ne plafonne pas le nombre de nœuds sur un bus ; la limite vient de la capacité d'entrée des transceivers et de la charge du bus, ce qui est une contrainte d'ingénierie de couche physique, pas une règle de protocole. DroneCAN, en revanche, a bien une limite stricte : 127 ID de nœud, parce que le schéma d'adressage fait 7 bits de large.

Pourquoi SMBus plafonne là où il plafonne

Le plafond de longueur de câble de SMBus n'est pas arbitraire. La spécification SMBus 2.0 plafonne la capacité totale du bus à 400 pF. Un câble bifilaire standard présente environ 50-100 pF par mètre selon sa construction, et chaque prise d'appareil et connecteur ajoute sa propre capacité parasite par-dessus. En faisant le calcul, on arrive à environ un demi-mètre de câble praticable avant que les marges de synchronisation du bus ne commencent à s'éroder et que le maître ne commence à voir des erreurs de bits.

C'est la vraie raison pour laquelle SMBus est un protocole « batterie vers hôte », pas un protocole « batterie vers n'importe quoi sur la cellule aérienne ». Il a été conçu pour un appareil situé juste à côté de la batterie, comme le circuit de gestion d'énergie d'un ordinateur portable, pas pour un signal parcourant un longeron d'aile de deux mètres jusqu'au contrôleur de vol. La convention de maître unique utilisée dans les conceptions de batteries intelligentes aggrave cela : sans un second maître sur le bus contre lequel arbitrer, il n'y a aucune raison d'intégrer cette complexité, si bien que SMBus reste simple par conception en pratique, et c'est exactement cette simplicité qui limite sa portée.

À l'intérieur de la trame : à quoi ressemble réellement un message BMS sur le fil

Les tableaux comparatifs vous disent quel protocole choisir. Ils ne vous disent pas quoi faire une fois que vous avez choisi CAN ou DroneCAN et que vous devez réellement définir le message qui porte les données de tension de cellule et de température de votre BMS. C'est la partie que tout article généraliste de présentation de protocole passe sous silence.

ID d'arbitrage CAN, DLC et priorité

Une trame CAN classique est construite autour de trois champs qui comptent pour la conception du BMS : l'ID d'arbitrage, le code de longueur de données (DLC), et la charge utile elle-même, jusqu'à 8 octets.

L'ID d'arbitrage (11 bits en CAN 2.0A standard, 29 bits en CAN 2.0B étendu) remplit deux fonctions à la fois. Il identifie le type de message, et il fixe la priorité. L'arbitrage CAN fonctionne avec des bits dominants : un 0 logique l'emporte sur un 1 logique lorsque deux nœuds émettent en même temps. Cela signifie qu'un ID numériquement plus bas gagne toujours l'arbitrage et est envoyé en premier. Un pack bien conçu réserve les ID bas aux messages critiques pour la sécurité (sous-tension de cellule, surchauffe, défaut BMS) et les ID plus hauts à la télémétrie de routine (état de charge, nombre de cycles), de sorte qu'un message de défaut passe toujours, même lorsque le bus est occupé par un scrutage de routine.

Le champ DLC indique combien d'octets de données suivent, de 0 à 8 en CAN classique. Une trame de diffusion BMS typique pourrait répartir ses 8 octets comme suit : 2 octets pour la tension du pack (little-endian, millivolts), 2 octets pour le courant du pack (signé, milliampères), 1 octet pour l'état de charge (0-100 %), 1 octet pour la température (encodée avec décalage et échelle), et 2 octets pour des indicateurs d'état ou un compteur cyclique. Il n'existe aucune norme universelle fixant ces décalages d'octets précis. C'est une disposition que l'on conçoit et documente une fois par projet, et c'est exactement le genre d'interface de communication BMS sur mesure qui doit être spécifiée par écrit lors d'une intégration de pack, avant que le firmware ne soit écrit des deux côtés.

Le transport par octet de fin de DroneCAN

DroneCAN ajoute une couche de transport par-dessus les trames CAN brutes pour faire circuler des messages plus grands que 7 octets de charge utile (DroneCAN réserve le 8e octet de chaque trame à son propre usage, décrit ci-dessous).

Chaque trame CAN DroneCAN se termine par un octet de fin regroupant quatre champs dans un seul octet : un drapeau de début de transfert, un drapeau de fin de transfert, un bit de bascule, et un ID de transfert de 5 bits. Un message qui tient en 7 octets ou moins part sous forme d'une trame unique avec les drapeaux de début et de fin tous deux positionnés. Un message plus grand, comme un rapport complet d'état de batterie regroupant tension, courant, température et champs d'état de santé, est scindé en plusieurs trames : la première trame positionne le drapeau de début, la dernière le drapeau de fin, et le bit de bascule s'inverse à chaque trame intermédiaire, permettant au récepteur de détecter une trame perdue ou dupliquée dans la séquence.

L'adressage des nœuds fonctionne également différemment. Plutôt que chaque nœud dispose d'une adresse fixe et préconfigurée, les nœuds DroneCAN sans ID assignée diffusent une demande d'allocation anonyme, et un nœud coordinateur (ou, dans une configuration à coordinateur unique, le contrôleur de vol lui-même) leur attribue un ID de nœud de 1 à 127. C'est ce qui permet de brancher une batterie compatible DroneCAN sur un aéronef inconnu et de la voir apparaître sans configurer manuellement une adresse, au prix de ce plafond fixe de 127 nœuds.

Exemple détaillé : décoder un message BatteryInfo de bout en bout

Parcourons ce qui se passe lorsqu'un BMS compatible DroneCAN rapporte son statut. Conceptuellement :

1. Le BMS assemble un message d'état de batterie : tension, courant, pourcentage de capacité restante, température, et un champ statut/santé. Cette charge utile dépasse 7 octets.
2. La pile DroneCAN du BMS scinde la charge utile en blocs séquentiels de 7 octets et ajoute un octet de fin à chacun, en partageant un même ID de transfert entre tous les blocs de cette transmission.
3. La première trame CAN part avec le bit de début de transfert de l'octet de fin positionné. Son ID d'arbitrage encode le type de message et l'ID de nœud propre au BMS, de sorte que tout nœud à l'écoute (contrôleur de vol, passerelle de station sol, enregistreur) sait à quoi il a affaire avant même de lire la charge utile.
4. Les trames suivantes portent les blocs de charge utile restants, chacune avec le bit de bascule inversé par rapport à la trame précédente. Si le récepteur voit deux trames consécutives avec le même état de bascule, il sait qu'une trame a été perdue et rejette le message partiel plutôt que d'assembler des données corrompues.
5. La dernière trame positionne le bit de fin de transfert. Le récepteur concatène tous les blocs de charge utile dans l'ordre et décode la structure complète de l'état de la batterie.
6. Si le contrôleur de vol ne reconnaît pas encore l'ID de nœud du BMS, tout cet échange est précédé par la négociation d'allocation dynamique décrite ci-dessus.

Le point clé sur le plan technique : l'octet de fin de DroneCAN transforme un bus limité à des trames de 8 octets en un bus capable de porter des messages structurés de taille arbitraire, au prix d'un octet de charge utile par trame et de la complexité supplémentaire de la logique de réassemblage aux deux extrémités.

Couche physique et CEM : ce qui détruit réellement l'intégrité du signal CAN sur un châssis de drone ou de robot

C'est la section que tout article concurrent passe sous silence, et c'est généralement là qu'un bus qui fonctionnait parfaitement sur la paillasse commence à perdre des trames en vol.

La transmission différentielle de CAN est réellement robuste face au bruit en mode commun ; c'est tout l'intérêt d'utiliser deux fils plutôt qu'un seul référencé à la masse. Mais robuste ne veut pas dire immunisé, et un châssis de drone ou de robot présente trois sources de bruit qu'un banc de paillasse n'a pas : la commutation des ESC/contrôleurs moteur à des dizaines de kilohertz, des pics de courant à fort di/dt sur le câblage de puissance, et des retours de masse partagés entre les chemins de puissance et de signal.

Terminaison. Un bus CAN nécessite une résistance de 120 ohms à chaque extrémité physique du bus, donnant une impédance de terminaison différentielle combinée d'environ 60 ohms. Une terminaison absente ou mal placée provoque des réflexions de signal qui se lisent comme des erreurs de bits intermittentes, pas comme un défaut franc, ce qui en fait l'un des problèmes CAN les plus difficiles à diagnostiquer sans oscilloscope sur le bus.

Topologie. CAN est conçu comme un bus linéaire à courtes dérivations, pas comme une étoile. Les longues dérivations depuis le tronc principal se comportent comme des antennes non terminées et renvoient de l'énergie de signal dans le bus. Gardez les dérivations courtes (quelques centimètres, pas des dizaines) partout où un nœud se raccorde au tronc principal.

Choix du câble et du connecteur. La paire torsadée n'est pas optionnelle ; c'est elle qui, en premier lieu, permet à la transmission différentielle de fonctionner contre le bruit en mode commun. Les connecteurs JST-GH et Molex Micro-Fit sont courants sur les aéronefs de drones plus petits, où la place sur la carte est réduite ; le XT30 apparaît davantage sur les plateformes robotiques, où le connecteur doit aussi survivre aux vibrations et aux cycles d'accouplement répétés. Quel que soit votre choix, gardez la torsion de la paire CAN intacte jusqu'aux broches ; défaire la torsion au niveau du connecteur pour économiser de la place annule l'intérêt de l'utiliser.

Retours de masse partagés. La plus grande erreur CEM sur un châssis de drone ou de robot consiste, de loin, à faire passer la référence de masse du CAN par le même chemin de retour que le courant de phase moteur. Chaque ampère de courant de commutation traversant une masse partagée crée une chute de tension qui se manifeste comme du bruit en mode commun sur la paire CAN. Atténuez ce risque en donnant à CAN (et à tout autre bus de signal bas niveau) son propre retour de masse vers un point unique, séparé du chemin de retour à fort courant du moteur et de l'ESC, et en gardant la paire torsadée CAN physiquement éloignée des câbles de phase moteur et des nœuds de commutation ESC, plutôt que regroupée avec eux dans le même faisceau.

Dans l'analyse concurrentielle menée par Dan-Tech sur les contenus les mieux classés sur ce sujet, aucun des articles ne chiffre les valeurs de terminaison, les limites de longueur de dérivation, ou la séparation des retours de masse. C'est là le manque : les tableaux comparatifs vous disent quel protocole choisir, mais pas comment le câbler pour qu'il survive à l'aéronef dans lequel il est intégré.

Quand le bus tombe en panne : états d'erreur, chiens de garde, et dégradation maîtrisée

Une comparaison de protocoles qui s'arrête à « CAN est plus robuste » sans expliquer ce qui se passe en cas de défaillance ne vous donne pas de quoi concevoir un système sûr autour.

Le mécanisme de comptage d'erreurs de CAN. Chaque contrôleur CAN maintient un compteur d'erreurs à l'émission (TEC) et un compteur d'erreurs à la réception (REC). Une erreur de bus détectée incrémente le compteur concerné ; une transmission ou une réception propre le décrémente. Au-delà de 127 sur l'un ou l'autre compteur, le nœud entre en état Error Passive, où il peut encore recevoir normalement mais perd une partie de sa capacité à imposer des bits dominants lors de l'arbitrage. Au-delà de 255, le nœud passe entièrement en Bus-Off, se déconnectant du bus pour protéger le reste du réseau d'un émetteur potentiellement défaillant. La reprise après un Bus-Off nécessite, selon l'implémentation, soit une séquence de récupération définie (128 occurrences observées sur le bus de 11 bits récessifs consécutifs), soit une réinitialisation du contrôleur.

Cela compte pour la conception de pack, car un BMS qui passe en Bus-Off à cause d'un connecteur bruité, et non d'un véritable défaut de pack, cesse entièrement de rapporter. Si la logique de sécurité intégrée du contrôleur de vol ou de mouvement ne peut pas distinguer « la batterie va bien, la connexion au bus est dégradée » de « la batterie est en panne », elle prendra la mauvaise décision exactement dans la situation où il importe le plus de la prendre correctement.

Motifs de battement de cœur et de chien de garde. Les nœuds DroneCAN diffusent un message périodique de statut/battement de cœur (environ une fois par seconde dans les implémentations typiques), spécifiquement pour qu'un auditeur puisse détecter un nœud bloqué même lorsqu'aucune condition d'erreur ne s'est techniquement produite. Si le contrôleur de vol cesse de voir ce battement de cœur dans un délai défini, il traite le nœud comme défaillant, pas simplement silencieux. SMBus n'a pas d'équivalent natif au battement de cœur ; un hôte qui interroge une batterie SMBus doit définir sa propre politique de délai de lecture et de nouvelle tentative, car un bus silencieux et un bus occupé se ressemblent sinon en tout point.

Dégradation maîtrisée. La bonne réponse à des données de batterie périmées est un délai de péremption, pas une attente indéfinie de la prochaine bonne lecture. Si la télémétrie CAN ou DroneCAN n'a pas été mise à jour dans une fenêtre définie, le contrôleur doit signaler l'état de la batterie comme inconnu plutôt que de continuer à faire confiance à la dernière valeur, et ce signalement doit alimenter la même logique de sécurité (avertissement, retour au point de départ, arrêt contrôlé) qu'un véritable événement de sous-tension déclencherait. Pour SMBus, l'équivalent est un nombre borné de tentatives de lecture échouées avant que le même repli ne s'enclenche. Dans tous les cas, le mode de défaillance contre lequel il faut concevoir est un contrôleur qui continue de voler ou de rouler sur des données auxquelles il ne devrait plus faire confiance.

Choisir le protocole : un cadre de décision pour l'intégration OEM

Passez outre le « ça dépend » et travaillez plutôt à travers quatre variables concrètes.

Nombre de nœuds. Une batterie, un hôte, rien d'autre sur le bus : SMBus est réellement plus simple à implémenter et à déboguer, et il n'y a aucune raison de porter la complexité supplémentaire de CAN pour une liaison qui n'en aura jamais besoin. Plus d'une poignée d'appareils partageant un bus (BMS, ESC, GPS, capteurs périphériques) : c'est le territoire de CAN ou DroneCAN, pas de SMBus.

Cadence de mise à jour requise. Le débit de classe 100 kHz de SMBus suffit largement pour une batterie qui rapporte une ou deux fois par seconde. Si votre application a besoin de mises à jour de télémétrie sous 100 ms sur plusieurs nœuds partageant la bande passante, le débit supérieur de CAN et son arbitrage multi-maître gèrent la contention de bus bien mieux qu'une liaison SMBus à maître unique ne le pourra jamais.

Exposition aux perturbations électromagnétiques. Une batterie logée dans un boîtier blindé à côté d'un unique hôte basse puissance est un environnement à faible CEM, où la couche physique plus simple de SMBus est un compromis raisonnable. Un pack câblé à travers un aéronef ou un châssis à côté de contrôleurs moteur est un environnement à forte CEM, où la transmission différentielle de CAN et la discipline de couche physique détaillée ci-dessus représentent le bon investissement.

Pile de vol ou de mouvement. Si la plateforme fonctionne sous PX4 ou ArduPilot, DroneCAN vous apporte un support natif et un dictionnaire de messages standardisé sans écrire de pilote personnalisé côté autopilote, ce qui représente un vrai gain de temps d'intégration. Si la plateforme fonctionne sous une pile de contrôleur de vol ou de mouvement propriétaire, le CAN brut avec une disposition de trame définie sur mesure (selon la conception d'ID d'arbitrage et de DLC détaillée ci-dessus) vous donne un contrôle total sur le format de message sans hériter du plafond d'ID de nœud ni de la surcharge de transport de DroneCAN.

Topologies CAN multi-BMS et packs en parallèle pour les plateformes industrielles et robotiques plus grandes

Les plateformes industrielles et robotiques de plus grande taille font de plus en plus fonctionner plusieurs packs de batteries en parallèle, chacun avec son propre BMS, partageant un seul bus CAN vers un contrôleur central. C'est un scénario réellement pertinent pour Dan-Tech en conception de pack sur mesure, et c'est un manque dans les contenus les mieux classés sur ce sujet, identifié par l'analyse concurrentielle de Dan-Tech.

Le problème de conception central est la collision des ID d'arbitrage. Si chaque BMS sur un bus multi-pack essaie d'utiliser le même ID d'arbitrage pour « tension de pack », le bus n'a aucun moyen de distinguer de quel pack provient la lecture qui vient d'arriver. La solution est une convention d'allocation d'ID conçue à cet effet : réservez un bloc d'ID par type de message, puis utilisez un sous-champ à l'intérieur de ce bloc (ou les bits de poids faible de la trame) pour porter un numéro d'instance de pack, de sorte que le message de tension du pack 1 et celui du pack 4 occupent des ID d'arbitrage distincts et ordonnés de manière déterministe. Les messages critiques pour la sécurité (le défaut ou la sous-tension de chaque pack individuel) conservent tout de même les ID les plus bas dans l'ensemble du schéma, de sorte que le défaut d'un pack atteigne le contrôleur avant la télémétrie de routine de tout autre pack sur le bus, quel que soit le pack qui le signale.

DroneCAN contourne une partie de ce problème par conception : son service d'allocation dynamique d'ID de nœud attribue déjà à chaque BMS un ID de nœud unique (1-127) sans qu'un humain ait à concevoir une convention de numérotation. Le compromis reste le même plafond de 127 nœuds évoqué plus haut, qui constitue rarement une contrainte réelle pour une plateforme industrielle multi-pack, mais qu'il vaut la peine de vérifier par rapport à votre nombre réel de nœuds (unités BMS plus tout autre appareil DroneCAN) avant de vous engager sur le protocole à grande échelle.

Décisions clés : résumé

• SMBus est le bon choix pour une batterie unique dialoguant avec un hôte proche unique, et sa limite pratique de longueur de câble d'environ 0,5 m découle directement du plafond de capacité de bus de 400 pF de la spécification SMBus 2.0, pas d'un choix de conception arbitraire.
• CAN est le bon choix dès que plus d'une poignée de nœuds partagent un bus, que l'exposition aux perturbations électromagnétiques est réelle, ou que vous définissez un format de message sur mesure pour une pile de vol ou de mouvement propriétaire. L'ID d'arbitrage sert également de priorité de message : les ID numériquement plus bas gagnent toujours.
• DroneCAN est le bon choix lorsque la plateforme fonctionne déjà sous PX4 ou ArduPilot, apportant un support natif et un dictionnaire de messages standardisé. Son transport par octet de fin permet aux messages multi-trames de dépasser la limite de 8 octets par trame de CAN, et son allocation dynamique d'ID de nœud supprime la configuration manuelle d'adresse, au prix d'un plafond de 127 nœuds.
• La discipline de couche physique (terminaison 120 ohms à chaque extrémité du bus, dérivations courtes, paire torsadée maintenue intacte jusqu'au connecteur, et retour de masse CAN maintenu séparé des chemins de courant moteur/ESC) prévient la plupart des défauts CAN intermittents et difficiles à diagnostiquer observés sur les châssis de drones et de robots.
• Concevez pour une dégradation maîtrisée, pas seulement pour la détection : un délai de péremption sur la télémétrie de la batterie, associé à la même logique de sécurité qu'un véritable événement de sous-tension déclencherait, est ce qui empêche un défaut de bus de se transformer en une décision de vol ou de mouvement non commandée.
• Les bus multi-BMS ont besoin d'une convention d'allocation d'ID conçue à l'avance, avant que le deuxième pack ne soit ajouté au bus, pas après qu'une collision d'arbitrage n'apparaîsse en test.

FAQ

DroneCAN est-il la même chose que CAN ?

Non. DroneCAN fonctionne sur la même couche physique que le CAN classique (CAN 2.0), mais il ajoute son propre schéma d'adressage, son dictionnaire de messages, et son protocole de transport par octet de fin pour les messages multi-trames. Un transceiver CAN est nécessaire pour DroneCAN, mais une trame CAN brute dépourvue de l'octet de fin et des conventions d'ID de nœud de DroneCAN n'est pas un message DroneCAN valide.

Pourquoi mon bus CAN fonctionne-t-il sur la paillasse mais perd-il des trames une fois installé dans l'aéronef ?

La cause la plus courante est un couplage électromagnétique via un retour de masse partagé avec le courant de commutation du moteur ou de l'ESC, suivi d'une terminaison de 120 ohms absente ou incorrecte et de longues dérivations non terminées. Les montages de paillasse présentent rarement l'un de ces trois problèmes ; les aéronefs installés presque toujours, sauf si le faisceau a été spécifiquement acheminé pour les éviter.

Combien de nœuds puis-je placer sur un bus CAN ?

CAN lui-même ne fixe pas de limite stricte de nœuds ; la contrainte réelle est la capacité d'entrée des transceivers et la charge totale du bus, ce qui limite en pratique la plupart des conceptions de bus CAN embarquées à quelques dizaines de nœuds par segment. DroneCAN ajoute sa propre limite séparée : un plafond de 127 nœuds issu de son champ d'ID de nœud sur 7 bits.

Puis-je utiliser SMBus pour un bus de télémétrie multi-nœuds à travers un aéronef de drone ?

Pas de manière fiable. L'usage conventionnel à maître unique de SMBus et sa limite pratique de longueur de câble d'environ 0,5 mètre (liée à son plafond de capacité de bus de 400 pF) le rendent adapté à une liaison batterie-vers-hôte, pas à un bus partagé par plusieurs appareils répartis sur un aéronef ou un châssis.

Que se passe-t-il si un nœud BMS de mon bus CAN passe en Bus-Off ?

Le nœud cesse entièrement d'émettre pour protéger le reste du bus d'un émetteur potentiellement défaillant, sur la base du franchissement de 255 par son compteur d'erreurs à l'émission. La reprise nécessite soit une séquence définie de récupération bus-idle, soit une réinitialisation du contrôleur. Concevez votre logique de sécurité pour traiter un battement de cœur manquant ou une télémétrie périmée comme « statut inconnu », pas comme « la batterie va bien », afin qu'un défaut de bus ne soit pas confondu avec une lecture propre.

Vous spécifiez une interface de communication pour un pack de batteries sur mesure ? Dan-Tech Energy, fabricant de packs de batteries Li-ion sur mesure avec une production en Allemagne et aux États-Unis, intègre sur demande des variantes de connecteurs compatibles CAN, SMBus et DroneCAN dans les packs pour drones et robotique. Commencez à cadrer vos besoins dans la ToolBox, ou parcourez l'ensemble du catalogue de packs de batteries Lithium-Ion pour voir les options de cellules et de configuration.

Lecture complémentaire :

• BMS sur mesure pour packs de batteries de drones : que spécifier et pourquoi c'est important : la décision PCM vs BMS, un niveau au-dessus du détail protocolaire de cet article.
• Comment spécifier un pack de batteries UAV sur mesure : un guide pour les OEM de drones : le processus complet de spécification de pack, dont l'interface de communication n'est qu'un élément.