CAN, RS485 et CANopen : de quelle communication une batterie de robot a-t-elle besoin ?

UN batterie de robot a besoin d'une interface et d'un protocole de communication adaptés au contrôleur du robot, au chargeur, aux exigences en matière de données BMS et à l'architecture réseau. CAN fonctionne bien pour la communication basée sur les priorités entre plusieurs nœuds. RS485 fournit une interface série différentielle robuste et est souvent associé à un protocole d'application tel que Modbus RTU. CANopen ajoute un cadre de communication standardisé de couche supérieure au-dessus de CAN.

Il n’existe pas de méthode de communication unique que chaque AGV ou AMR devrait utiliser. Pour fiable batterie de robot communication, la compatibilité doit s’étendre au-delà du connecteur. L'interface électrique, le débit binaire ou en bauds, la structure des messages, le mappage des données, l'adressage, la synchronisation, le comportement en cas de panne et la logique de charge doivent tous correspondre au système hôte.

De quoi une batterie de robot a-t-elle besoin pour communiquer ?

UN batterie de robot communique car le robot a besoin de plus que de l’énergie électrique. Son système de gestion de batterie doit mettre les conditions de batterie et les limites de fonctionnement sélectionnées à la disposition d'équipements tels que le contrôleur du véhicule, le chargeur, la station de chargement, l'ordinateur de diagnostic ou la passerelle de gestion de flotte.

Données de batterie dont le robot a besoin

Un BMS pour batterie AMR mesure ou calcule plusieurs catégories d’informations. Le contrôleur n'a peut-être pas besoin de chaque valeur de cellule interne en permanence, mais il doit recevoir les données requises pour le fonctionnement, la charge, les diagnostics et la maintenance.

Catégorie de données	Informations typiques	Comment le robot utilise it
État électrique	Tension du pack, courant, capacité restante	Surveille l'état actuel de la batterie
État thermique et cellulaire	Tension des cellules, température du pack, température des cellules	Prend en charge les décisions de protection et d’exploitation
Estimations de batterie	SOC, SOH	Prend en charge la planification de l'exécution et de la maintenance
Limites de fonctionnement	Courant de charge, courant de décharge, tension de charge	Aide à maintenir le fonctionnement dans les limites du BMS
Données de défauts et d'avertissements	Surtension, sous-tension, surchauffe, surintensité	Prend en charge la réponse aux pannes contrôlée
État du système	Charge, décharge, veille, état de protection	Coordonne le comportement du robot
Identification	Adresse de l'appareil, version du protocole, identité de la batterie	Prend en charge la reconnaissance et le service

Ceci est également cohérent avec la conception moderne des BMS de robotique mobile. Les plates-formes de référence BMS orientées robotique de NXP combinent la mesure de la tension des cellules et des packs, la détection du courant, la détection de la température et la connectivité CAN au sein de la même architecture de gestion de batterie.

Les spécifications de communication d'une batterie de robot doivent donc commencer par les données dont le robot a besoin, plutôt que par un connecteur ou un nom de bus préféré.

SOC, SOH et rapports de défauts

SOC donne au robot une estimation de la charge restante, tandis que SOH représente l'état de la batterie à plus long terme. Les deux sont précieux, mais aucun ne doit être considéré comme une exigence de communication complète.

UN batterie de robot peut également signaler les températures, le courant, les états d'avertissement, les conditions de protection et les limites de charge ou de décharge autorisées. Lorsque les conditions de fonctionnement changent, ces valeurs fournissent au contrôleur du véhicule des informations qu'il peut utiliser avant que le BMS n'atteigne un état de protection strict.

Cela rend la communication avec la batterie du robot utile à la fois pour le fonctionnement et la maintenance immédiats. Le logiciel de flotte peut utiliser des informations cohérentes sur l'état et les défauts pour distinguer une condition de faible consommation d'énergie d'un événement thermique, d'un événement de protection ou d'un défaut de communication.

Poignées de main du contrôleur et du chargeur

Le contrôleur du véhicule et le chargeur ne nécessitent pas nécessairement des données de batterie identiques. Pendant le mouvement, le contrôleur peut donner la priorité au SOC, à la tension, au courant, à la température, aux avertissements et aux limites de décharge. Pendant la charge, le système peut également avoir besoin d'une autorisation de charge, de limites de courant de charge, de limites de tension, d'informations sur l'état de la température et sur l'état de charge.

C'est pourquoi la spécification d'un BMS de batterie CAN ou d'un BMS de batterie RS485 n'est que la première étape. Deux appareils peuvent partager la même interface électrique tout en utilisant des identifiants, des registres, des facteurs d'échelle, des intervalles de mise à jour ou une logique de contrôle différents.

La recharge automatique rend la distinction particulièrement importante. Lorsqu'un AGV ou un AMR s'amarre sans intervention de l'opérateur, la batterie, le chargeur et le contrôleur du robot doivent avoir un comportement défini pour l'autorisation de charge, les limites de fonctionnement, la gestion des pannes, l'achèvement de la charge et la remise en service.

Pourquoi la communication affecte la disponibilité

Une communication utile avec la batterie permet au robot de réagir aux conditions de la batterie avant qu'un arrêt brutal ne devienne la seule réponse disponible. Un faible SOC peut lancer une tâche de charge, une condition de température peut affecter le comportement de charge et un défaut signalé peut placer le véhicule dans un état de service défini.

Pour les flottes, des données cohérentes sur les batteries des robots améliorent également le dépannage. Les équipes de maintenance peuvent examiner les états de fonctionnement et les alarmes au lieu de traiter chaque perte de propulsion ou interruption de charge comme le même problème.

L’avantage n’est pas simplement davantage de télémétrie. La véritable valeur réside dans le fait de faire de la batterie une partie intégrée et interprétable de l’architecture de contrôle du robot.

CAN vs RS485 : en quoi ils diffèrent dans les systèmes robotisés

CAN et RS485 sont tous deux courants dans les systèmes industriels, mais ils résolvent différentes parties du problème de communication. CAN fournit des mécanismes de tramage de messages, d'arbitrage, d'accusé de réception et de gestion des erreurs pour un bus partagé. RS485 définit principalement la signalisation électrique utilisée pour la communication série.

Cette distinction est importante lorsque les ingénieurs sélectionnent une architecture de communication pour une batterie de robot.

CAN en tant que réseau

CAN est conçu pour plusieurs appareils communiquant sur un bus partagé. Les messages sont identifiés par des identifiants CAN et les tentatives de transmission simultanées sont résolues grâce à un arbitrage basé sur les priorités.

Pour la communication avec la batterie du robot, cette architecture peut prendre en charge des messages d'état réguliers, des limites de fonctionnement, des informations d'avertissement et des rapports de pannes déclenchés par des événements. La conception de référence actuelle du BMS de robotique mobile MR-BMS771 de NXP comprend deux bus CAN, fournissant un exemple pratique d'intégration directe de CAN dans une plate-forme robotique de gestion de batterie.

Un port CAN à lui seul ne définit cependant pas la signification des données. Un BMS de batterie CAN et un contrôleur de robot ont toujours besoin de débits binaires, d'identifiants, de définitions de charge utile, de mise à l'échelle, de synchronisation de transmission et de logique d'application compatibles.

RS485 comme interface physique

RS485 est une interface série différentielle largement utilisée dans la communication multipoint industrielle. Il est particulièrement utile lorsque l'équipement utilise déjà des réseaux série ou lorsqu'un contrôleur communique avec plusieurs appareils adressés.

Pour une batterie de robot, le point critique est que le RS485 à lui seul n'indique pas au contrôleur la signification d'un octet. Un BMS de batterie RS485 nécessite toujours un protocole d'application défini ou une structure de données propriétaire.

Cette distinction explique pourquoi RS485 et Modbus RTU apparaissent fréquemment ensemble sans être synonymes. L'organisation Modbus documente les implémentations de ligne série Modbus à l'aide d'EIA/TIA-485, tandis que Modbus définit lui-même le comportement de messagerie de niveau supérieur.

Une spécification d’achat devrait donc dire plus que “ RS485 requis ”. Il doit identifier le protocole réel et la carte de données attendus par le robot.

Arbitrage CAN et gestion des erreurs

CAN permet aux nœuds de transmettre sans attendre qu'un contrôleur central attribue chaque opportunité de transmission. Si deux nœuds commencent à transmettre en même temps, l'arbitrage basé sur les identifiants de message détermine quelle trame continue.

CAN comprend également des mécanismes pour détecter les erreurs de transmission et gérer les nœuds qui génèrent des erreurs de manière répétée. Ces caractéristiques le rendent adapté aux réseaux où le batterie de robot doit échanger fréquemment des données d’exploitation avec d’autres contrôleurs.

La décision technique ne doit pas être réduite à une affirmation générique selon laquelle CAN est simplement “ plus rapide ”. Ce qui compte est de savoir si les messages de batterie requis peuvent être transmis avec la priorité et le timing de mise à jour nécessaires sous la charge de bus attendue.

Pour un robot mobile, un petit ensemble de messages de batterie correctement hiérarchisés et documentés est souvent plus précieux qu'un débit de données théoriquement élevé avec un comportement d'application mal défini.

Modbus RTU sur RS485

Modbus RTU fournit une structure de messagerie au niveau de l'application qui peut fonctionner sur une liaison série RS485. Le protocole définit la manière dont les appareils adressés échangent des demandes et des réponses, tandis que la carte de registre spécifique à l'équipement identifie l'emplacement de stockage des valeurs individuelles.

Pour une batterie de robot, une carte Modbus RTU peut contenir des registres pour la tension, le courant, le SOC, la température, les alarmes ou les limites de fonctionnement du pack. Une interprétation correcte nécessite que le contrôleur connaisse l'adresse du registre, le format des données, le facteur de mise à l'échelle, l'ordre des octets, l'adresse du périphérique, le débit en bauds, la parité et le comportement du délai d'attente.

Plusieurs distinctions sont importantes lors de l'intégration : RS485 ne signifie pas automatiquement Modbus RTU ; deux appareils Modbus n'utilisent pas automatiquement la même carte de registre ; un connecteur RJ45 n'établit pas la compatibilité Ethernet, CAN ou RS485 ; et une connexion électriquement valide ne garantit pas la compatibilité au niveau de l'application.

Ces contrôles évitent un échec d’intégration courant : les deux parties semblent prendre en charge la même technologie de communication, mais la batterie du robot et le contrôleur ne peuvent pas comprendre les données de chacun.

Où CANopen s'intègre dans un système de batterie de robot

CANopen se situe au-dessus de CAN dans la pile de communication. Il ne remplace pas le bus CAN. Au lieu de cela, CANopen définit des mécanismes standardisés pour organiser les données des appareils, transmettre les informations sur les processus, accéder aux paramètres de configuration, contrôler les états du réseau et surveiller les participants au réseau.

Une implémentation de batterie CANopen nécessite donc plus qu'un émetteur-récepteur CAN ou un connecteur CAN. Le BMS doit implémenter les fonctions CANopen requises par le contrôleur hôte.

CAN n'est pas CANopen

CAN fournit le mécanisme de communication réseau sous-jacent. CANopen ajoute la structure de couche supérieure qui détermine la manière dont les appareils basés sur CAN organisent et échangent les données d'application.

CAN in Automation, ou CiA, décrit un appareil CANopen comme doté d'une pile de protocoles CANopen, d'un logiciel d'application et d'un dictionnaire d'objets qui connecte le système de communication aux paramètres d'application.

Cela rend une règle de passation des marchés particulièrement importante :

La prise en charge CAN ne signifie pas automatiquement la prise en charge CANopen.

Si un contrôleur AMR nécessite une batterie CANopen, la spécification doit identifier la fonctionnalité CANopen et les mappages de données attendus par le contrôleur. Il ne suffit pas de demander simplement un port CAN.

Le dictionnaire d'objets CANopen

Le dictionnaire d'objets est le modèle de données structurées utilisé par les appareils CANopen. CiA spécifie que les paramètres de communication et d'application sont organisés via des entrées de dictionnaire d'objets indexées, avec des valeurs d'index et de sous-index fournissant des adresses définies pour les données.

Dans une intégration de batterie CANopen, cette structure peut fournir un moyen cohérent d'exposer l'état de la batterie, les paramètres de configuration et les informations de diagnostic. Les objets de batterie réels doivent toujours correspondre aux exigences du contrôleur et à tout profil ou spécification de projet applicable.

L'avantage pratique est la clarté. Les ingénieurs n'ont pas besoin de traiter chaque trame CAN comme un message propriétaire isolé lorsqu'une implémentation CANopen définie est utilisée. Ils peuvent travailler avec des objets documentés et des services de communication.

PDO, SDO et diagnostics

CANopen sépare les différentes tâches de communication via des services définis. Les objets de données de processus, ou PDO, sont adaptés au traitement des informations échangées pendant le fonctionnement. Les objets de données de service, ou SDO, permettent d'accéder aux entrées du dictionnaire d'objets pour les fonctions de configuration et de service.

CANopen fournit également des mécanismes de rapport d'erreurs et de supervision des nœuds. La documentation CiA identifie les fonctions PDO, SDO, d'urgence, de battement de cœur et de gestion de réseau comme faisant partie de l'architecture de communication CANopen.

Pour une batterie CANopen, les valeurs de fonctionnement fréquemment requises peuvent être mappées dans la communication PDO, tandis que l'accès SDO peut prendre en charge la mise en service ou les diagnostics. La cartographie exacte doit être convenue avant l’intégration plutôt que supposée.

C'est également la raison pour laquelle une batterie de robot qui communique avec succès via CAN propriétaire ne peut pas automatiquement être considérée comme compatible CANopen.

Gestion du réseau et battements de cœur

CANopen Network Management, ou NMT, définit les états de communication d'un appareil. CiA identifie les états d'initialisation, pré-opérationnel, opérationnel et arrêté au sein de la machine à états CANopen NMT. La communication PDO devient disponible dans l'état opérationnel, tandis que la communication SDO peut être utilisée dans l'état pré-opérationnel.

Pour la communication avec la batterie du robot, ces états aident à définir le comportement lors du démarrage, de la mise en service, du fonctionnement normal, de l'arrêt et de la récupération.

Les mécanismes Heartbeat fournissent une autre fonction utile en permettant au contrôleur de déterminer si un nœud attendu reste présent sur le réseau. Une spécification de batterie CANopen doit donc couvrir plus que les champs de données sur la batterie. L’état de démarrage, le timing des battements de cœur, le délai d’attente et le comportement de récupération peuvent également être importants pour le robot.

Choisir la bonne interface pour les AGV et les AMR

La bonne méthode de communication est celle qui correspond à l’architecture de contrôle existante du robot et fournit les informations sur la batterie requises par ce système.

La sélection du protocole doit donc commencer par le contrôleur hôte et l'architecture de charge plutôt que par une préférence générique pour CAN ou RS485.

Faites correspondre le réseau de robots existant

La première étape consiste à déterminer exactement ce qu’attend le contrôleur du robot. Un contrôleur peut utiliser des trames CAN propriétaires, CANopen, RS485 avec Modbus RTU ou un autre protocole documenté.

Architecture existante	Exigence appropriée en matière de batterie du robot
Contrôleur CAN propriétaire	BMS de batterie CAN avec débit binaire et carte de messages correspondants
Contrôleur CANopen	BMS implémentant les objets CANopen requis et le comportement du réseau
Automate ou contrôleur utilisant Modbus RTU	BMS de batterie RS485 avec paramètres série correspondants et carte de registre
Réseaux de contrôle et de diagnostic séparés	Définir quelle connexion transporte le contrôle de la batterie et laquelle transporte les données de service

La batterie du robot doit être adaptée à ces exigences du réseau. Choisir un pack parce que son étiquette de connecteur ou de port semble familière inverse le processus d'ingénierie correct.

Définir les données de batterie requises

Avant de demander un pack personnalisé, les ingénieurs doivent créer une matrice de communication qui sépare les données nécessaires au fonctionnement des informations destinées principalement au diagnostic ou à la maintenance.

Pour de nombreux projets AGV et AMR, le batterie de robot les données comprennent :

• Tension et courant du paquet
• SOC et SOH
• Température de la batterie
• Limites de charge et de décharge
• États d'avertissement et de protection
• État de charge et état du BMS
• Identité de l'appareil ou adresse réseau
• État du contacteur ou du MOSFET lorsque le système l'exige

Le projet devrait également définir la direction des données. Certaines informations sont transmises du BMS de la batterie AMR à l'hôte, tandis que d'autres architectures peuvent nécessiter des commandes de contrôle, des accusés de réception ou des messages de configuration de la part du contrôleur.

Cette étape détermine ce que l'interface doit réellement accomplir.

Vérifier le timing et la réponse aux pannes

A complete communication specification needs timing requirements in addition to data definitions.

Engineers should determine how often critical robot battery information must be updated, how long the controller waits before declaring the BMS offline, and what response follows a communication timeout. CAN message priorities or RS485 polling intervals should reflect the importance of the data being transferred.

Fault recovery also needs defined behavior. The system should establish whether communication resumes automatically after a transient event, whether the BMS requires a reset, and whether the robot can resume operation immediately or must first verify battery status.

These decisions are application-specific. They should be documented during integration rather than inferred from the communication interface.

Planifier la communication de la station de recharge

An automatically charged AGV or AMR needs the charging dock considered as part of the batterie de robot architecture.

The charging system may need to coordinate charge permission, battery voltage, current limits, temperature state, charging status, completion, and fault conditions. Physical charging contacts or a contactless power receiver provide the power path, but they do not define the communication behavior.

The robot also needs a clear sequence for detecting the dock, enabling charging, responding to BMS limits, completing the charge process, and returning to operation.

MANLY Battery’s current AMR integration guidance identifies CAN or RS485 communication, current and temperature monitoring, connector design, and application-specific wiring as factors to coordinate when integrating an AMR battery, BMS, and charging dock.

For autonomous fleets, charging communication should therefore be designed at the same time as the robot battery and BMS rather than after the pack has already been finalized.

Tenir compte des besoins en matière de diagnostic de flotte

Control traffic and maintenance data do not always need to use the same communication path. Some robots place time-sensitive battery data on the primary CAN network while using a separate interface for commissioning, service, or deeper diagnostics.

What matters is that the diagnostic architecture is deliberate.

For large fleets, consistent robot battery data definitions can simplify troubleshooting across many vehicles. Fault codes, units, scaling, firmware versions, communication states, and maintenance records should have repeatable meanings from one robot to another.

This can become particularly valuable when fleet software is used to distinguish energy-related events from BMS faults, charger faults, or communication failures.

Que demander à un fabricant de batteries avant l'intégration

UN fabricant de batteries should be able to discuss BMS communication with the same engineering detail used for pack voltage, capacity, current, dimensions, and connector requirements.

“CAN available” or “RS485 available” is useful for initial screening, but a production robot battery requires a more complete communication specification.

Carte des protocoles et des messages

For CAN integration, request the application protocol, CAN identifiers, payload definitions, scaling, message direction, transmission timing, and timeout behavior.

For a CANopen battery, define the required object-dictionary entries, PDO mappings, SDO access, NMT behavior, heartbeat requirements, and controller-specific functions.

If the project uses manufacturer-specific CAN communication, the message definition should be available early enough for controller development and bench testing. The software team should not have to reverse-engineer the batterie de robot after prototype hardware arrives.

Débit en bauds et identifiants de nœud

Both sides of the connection must use compatible network settings.

For CAN, confirm the CAN bit rate and relevant identifier or node configuration. For CANopen, also define node IDs and required network-management behavior. For an RS485 battery BMS, confirm baud rate, parity, stop bits, addressing, and expected polling or response behavior.

These parameters should be recorded in the project communication specification and controlled like any other system-level interface requirement.

Enregistrer la mise à l'échelle de la carte et des données

An RS485 connection using Modbus RTU needs a complete register map. Every required value should have a defined address, data type, scaling factor, engineering unit, and access method.

For example, a transmitted value cannot be interpreted correctly until the controller knows whether it represents volts, millivolts, tenths of a volt, signed current, or another encoding.

The same principle applies to CAN. Receiving a valid CAN frame does not prove that the batterie de robot data has been interpreted correctly. Byte order, bit definitions, scaling, signed values, and status flags still have to match.

Terminaison, brochage et connecteurs

The electrical documentation should identify every required communication pin, including CAN-H, CAN-L, RS485-A, RS485-B, signal ground, wake lines, shielding, or other project-specific conductors.

Termination also has to match the selected network topology. Engineers should verify whether termination is inside the robot battery, installed elsewhere on the robot, configurable, or omitted.

Connector shape should never be used as a substitute for this documentation. An RJ45-style connector, for example, does not automatically indicate Ethernet and does not establish a standardized CAN or RS485 pinout.

The cable and connector design therefore belong in the communication specification, not just the mechanical drawing.

Exigences de communication du chargeur

The robot battery and charger should be engineered as a coordinated system when the charging process requires communication.

The specification should define whether the charger uses fixed electrical settings or receives dynamic limits from the BMS or vehicle controller. It should also document charge-enable logic, current and voltage limits, thermal behavior, charging status, charge completion, fault response, dock handshaking, and recovery after interrupted charging.

For an AGV or AMR that relies on unattended charging, these functions can directly affect how reliably the robot returns to operation after reaching the dock.

Options de communication de la batterie MANLY

At MANLY Battery, robot and industrial battery projects can be developed around the communication requirements of the application rather than treating the interface as an isolated add-on.

The MANLY 24V 50Ah robot battery is a LiFePO4 pack rated at 24V nominal, with a 25.6V actual battery voltage and 1,280Wh of nominal energy. Its current specification provides optional RS485, RS232, or CANBus communication. Dimensions, housing, connector, case, and wiring can also be configured for OEM/ODM requirements.

For industrial robots requiring greater onboard capacity, the MANLY 48V 100Ah robot battery provides 100Ah capacity and 4,800Wh nominal energy. It also supports optional RS485, RS232, or CANBus communication, with customizable dimensions, housing, connectors, and wiring.

MANLY robot battery	Communication	Objectif intégration
Batterie robot 24V 50Ah LiFePO4	Optional RS485, RS232, CANBus	Robot and AGV projects requiring configurable BMS communication, connectors, and pack dimensions
48V 100Ah industrial robot battery	Optional RS485, RS232, CANBus	Higher-capacity industrial robot applications requiring coordinated BMS, controller, charger, and pack integration

If a project specifically requires CANopen battery communication, that requirement should be defined during the engineering review. CANBus availability alone should not be treated as confirmation of CANopen compatibility.

The project team should provide the required CANopen object mapping, network configuration, controller behavior, and other protocol requirements so the implementation can be evaluated before the batterie de robot design is finalized.

For CAN or RS485 projects, the same principle applies. Providing the controller specification, message or register map, communication speed, pinout, charger architecture, voltage, capacity, current requirements, and expected fault behavior gives the battery manufacturer a much clearer integration target.

Le droit robot battery communication method is therefore not determined by choosing CAN, RS485, or CANopen in isolation. It is determined by whether the BMS, robot controller, charger, wiring, protocol, and operating logic have been designed to work together as one system.

En savoir plus sur la batterie