Bras Robot - Arduino ROS2 IA

Machine Learning LeRobot avec SO-ARM101

Installation et prérequis

Prérequis pour l'entraînement et l'exécution d'un modèle d'IA :

Installation sous Linux

wget https://repo.anaconda.com/miniconda/Miniconda3-latest-Linux-x86_64.sh
# Vérifier que la clé SHA256 de Miniconda3-latest-Linux-x86_64.sh ici : https://repo.anaconda.com/miniconda/ correspond à :
sha256sum ~/Miniconda3-latest-Linux-x86_64.sh
bash ~/Miniconda3-latest-Linux-x86_64.sh
source ~/.bashrc
conda create -y -n lerobot python=3.10
conda activate lerobot
git clone https://github.com/huggingface/lerobot.git ~/lerobot
conda install ffmpeg=7.1.1 -c conda-forge
cd ~/lerobot && pip install -e ".[feetech]"

Astuces pour activer/désactiver l'environnement conda sans passer par la modification du ~/.bashrc :

Installation Windows

conda create -y -n lerobot python=3.10
conda activate lerobot
git clone https://github.com/huggingface/lerobot.git ~/lerobot
cd ~/lerobot
# pip install av poetry-core
conda install ffmpeg=7.1.1 -c conda-forge
pip3 install --pre torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu128
pip install -e ".[feetech]"

Récupérer les infos système pour débuguer l'installation si les scripts basculent sur le cpu :

Banc de Machine Learning LeRobot

Configurer les servomoteurs

La carte FE-URT-1 fournie par Feetech n'est pas détectée sous Ubuntu à cause d'un conflit avec un paquet de brail. On le désinstalle : 

sudo apt-get autoremove brltty

https://askubuntu.com/questions/1321442/how-to-look-for-ch340-usb-drivers/1472246#1472246 

https://github.com/huggingface/lerobot/blob/main/examples/10_use_so100.md#c-configure-the-motors 

python lerobot/scripts/find_motors_bus_port.py
sudo chmod 666 /dev/ttyACM0
sudo chmod 666 /dev/ttyACM1

gedit ~/lerobot/lerobot/common/robot_devices/robots/configs.py

python lerobot/scripts/configure_motor.py \
  --port /dev/tty.usbmodem58760432961 \
  --brand feetech \
  --model sts3215 \
  --baudrate 1000000 \
  --ID 1

Ne plus bouger les servos jusqu'à l'assemblage

Construction et assemblage mécanique

Une version 101 est sortie en 05/2025. Le Leader est plus simple à assembler, et plus besoin de démonter les servos pour enlever un engrenage et les rendre passifs. Il suffit d'acheter le kit de 6 servos avec 3 rapports de transmission différents :

Astuces pour l'assemblage

image.png

Agencement des caméras et robots

Le nombre, le positionnement et la qualité des caméras sont importants pour la qualité du DataSet :

Au FabLab de IUT Haguenau

PXL_20250613_142740983_crop.jpg

Calibration des caméras

https://huggingface.co/docs/lerobot/cameras 

Utilisation de LeRobot

python lerobot/scripts/find_motors_bus_port.py

nano lerobot/common/robot_devices/robots/configs.py

python lerobot/scripts/control_robot.py   --robot.type=so101   --robot.cameras='{}'   --control.type=teleoperate

 

Calibration robot et configuration caméras

python -m lerobot.calibrate     --teleop.type=so101_leader  --teleop.port=/dev/ttyACM0 --teleop.id=leader_arm_fan1

python -m lerobot.calibrate     --robot.type=so101_follower     --robot.port=/dev/ttyUSB0 --robot.id=follower_arm_fan1

Téléopération

python -m lerobot.teleoperate \
    --robot.type=so101_follower \
    --robot.port=/dev/ttyUSB0 \
    --robot.id=follower_arm_fan1 \
    --robot.cameras="{ top: {type: opencv, index_or_path: 2, width: 640, height: 480, fps: 30},follower: {type: opencv, index_or_path: 4, width: 640, height: 480, fps: 30}}" \
    --teleop.type=so101_leader \
    --teleop.port=/dev/ttyACM0 \
    --teleop.id=leader_arm_fan1 \
    --display_data=true

Rejouer dataset en local :

python -m lerobot.replay \
    --robot.type=so101_follower \
    --robot.port=/dev/ttyUSB0 \
    --robot.id=follower_arm_fan1 \
    --dataset.repo_id=gautz/18650-test1-10ep \
    --dataset.episode=0 # choose the episode you want to replay

Machine Learning

Enregistrer dataset en local :

python -m lerobot.record \
    --robot.type=so101_follower \
    --robot.port=/dev/ttyUSB0 \
    --robot.id=follower_arm_fan1 \
    --robot.cameras="{ top: {type: opencv, index_or_path: 2, width: 640, height: 480, fps: 30},follower: {type: opencv, index_or_path: 4, width: 640, height: 480, fps: 30}}" \
    --teleop.type=so101_leader \
    --teleop.port=/dev/ttyACM0 \
    --teleop.id=leader_arm_fan1 \
    --display_data=true \
    --dataset.repo_id=gautz/18650-test1-10ep \
    --dataset.episode_time_s=10 \
    --dataset.reset_time_s=10 \
    --dataset.num_episodes=10 \
    --dataset.single_task="Pick red 18650 battery place black box" \
    --dataset.push_to_hub=False

Entrainer en local avec le cpu

python lerobot/scripts/train.py \
  --dataset.repo_id=gautz/18650-test1-10ep \
  --policy.type=act \
  --output_dir=outputs/train/act_so101_18650-test1-10ep \
  --job_name=act_so101_18650-test1-10ep \
  --policy.device=cpu # \
  --wandb.enable=false # true

Entrainer en local avec le GPU

python lerobot/scripts/train.py \
  --dataset.repo_id=gautz/18650-test1-10ep \
  --policy.type=act \
  --output_dir=outputs/train/act_so101_18650-test1-10ep \
  --job_name=act_so101_18650-test1-10ep \
  --policy.device=cuda \
  --wandb.enable=false

Enregistrer un dataset d'évaluation d'un modèle à un checkpoint donné :

python -m lerobot.record  \
--robot.type=so101_follower \
--robot.port=/dev/ttyUSB0 \
--robot.cameras="{ top: {type: opencv, index_or_path: 2, width: 800, height: 600, fps: 30},follower: {type: opencv, index_or_path: 4, width: 800, height: 600, fps: 30}}" \
--robot.id=follower_arm_fan1 \
--display_data=false \
--dataset.repo_id=gautz/eval_act_18650-test2-100ep \
--dataset.single_task="Pick red 18650 battery place black box" \
--policy.path=outputs/train/act_so101_18650-test2-100ep/checkpoints/last/pretrained_model \
--dataset.push_to_hub=False

Visualiser et rejouer des DataSets (avant hardware refactor)

python lerobot/scripts/visualize_dataset.py     --repo-id lerobot/pusht     --root ./my_local_data_dir     --local-files-only 1     --episode-index 0

python lerobot/scripts/visualize_dataset_html.py \
  --repo-id cadene/act_so100_5_lego_test_080000 \
  --local-files-only 1
python lerobot/scripts/control_robot.py \
  --robot.type=so101 \
  --control.type=replay \
  --control.fps=30 \
  --control.repo_id=cadene/act_so100_5_lego_test_080000 \
  --control.episode=0
python lerobot/scripts/control_robot.py \
  --robot.type=so101 \
  --control.type=record \
  --control.fps=30 \
  --control.single_task="Grasp a lego block and put it in the bin." \
  --control.repo_id=outputs/eval/act_so100_5_lego_test_080000_haguenau \
  --control.tags='["tutorial"]' \
  --control.warmup_time_s=5 \
  --control.episode_time_s=30 \
  --control.reset_time_s=30 \
  --control.num_episodes=10 \
  --control.push_to_hub=false \
  --control.policy.path=cadene/act_so100_5_lego_test_080000

Sources

https://wiki.seeedstudio.com/lerobot_so100m/ 

IA robotique - Architectures pour l'apprentissage profond

Le contrôle d'un robot pour une application donnée au moyen d'un modèle de réseaux de neurones nécessite de fournir une quantité importante de données d'apprentissage. Ces données doivent permettre de comprendre comment résoudre la tâche, par exemple pour une tâche de saisie et dépose d'un objet (Pick and Place) elles doivent donc comporter :

L'approche la plus répandue pour générer ces données d'apprentissage est la démonstration : le robot est "téléguidé" par un opérateur. On enregistre la trajectoire des servomoteurs ainsi qu'une ou plusieurs vidéos filmant les objets et le robot.

Bancs matériel de Machine Learning

Koch

LeRobot SO-ARM10X

PXL_20250613_153054943.jpg

Aloha Solo

Base : $9,899.95

image.png

https://www.youtube.com/watch?v=hFqZJZ666Cw 

Whole Product Shot Square.jpg

https://www.trossenrobotics.com/aloha-solo 

Aloha Stationary

Without Laptop : $30,799.98

aloha-stationary-mv-p2.jpg

Environnement logiciel de collecte de données

Hugging Face LeRobot - Python

Visualisation des DataSet : https://huggingface.co/spaces/lerobot/visualize_dataset 

On note qu'il y a beaucoup de tests avec le SO-ARM10X. Mais pas d'homogénéité dans la collecte de données : les caméras sont placées la plupart du temps devant le robot, parfois sur la pince, et quasiment jamais avec le setup recommandé.

Rechercher des DataSet qui ont servi à entrainer des modèles disponibles publiés :


Setup similaires à celui du SO-ARM10X simple :

Télécharger un DataSet : https://github.com/huggingface/lerobot/blob/a1daeaf0c4ae345df9b2f5b862f091ce158e4446/examples/1_load_lerobot_dataset.py 

Rejouer les épisodes d'un DataSet : https://github.com/huggingface/lerobot/blob/a1daeaf0c4ae345df9b2f5b862f091ce158e4446/examples/12_use_so101.md#replay-an-episode 

Evaluer un modèle pré-entrainé : https://github.com/huggingface/lerobot/blob/a1daeaf0c4ae345df9b2f5b862f091ce158e4446/examples/2_evaluate_pretrained_policy.py 

Trossen Robotics Interbotix - ROS, Python, 

Etat de l'art Bras robot low-cost

Modèles commerciaux fermés

Niryo Ned 2

https://niryo.com/fr/produit/bras-robotise-6-axes/ 

https://github.com/NiryoRobotics 

DAGU Six-servo Robot Arm

image.png

https://seafile.unistra.fr/d/693101e6046d4819a3af/ 

https://arexx.com/product/robot-arm/ 

www.arexx.com.cn 

Modèles Open Source

https://github.com/AntoBrandi/Robotics-and-ROS-2-Learn-by-Doing-Manipulators 

Trossen Robotics ALOHA

Stationary

https://docs.trossenrobotics.com/trossen_arm/main/specifications.html 

https://docs.trossenrobotics.com/aloha_docs/2.0/specifications.html#aloha-stationary 

https://docs.trossenrobotics.com/aloha_docs/2.0/operation/stationary.html 

Solo
Dimensions 1019D x 1066H x 1225W mm
Leader Arms WidowX 250 S - Aloha Version
Follower Arms ViperX 300 S - Aloha Version
Camera 2x Intel RealSense D405
Chassis Modular
Computer Coming Soon
USB Hubs Yes 1X

https://docs.trossenrobotics.com/aloha_docs/2.0/specifications.html#aloha-solo

https://docs.trossenrobotics.com/aloha_docs/2.0/operation/solo.html 

 Trossen Robotics (Interbotix) X-Series Arms

https://docs.trossenrobotics.com/interbotix_xsarms_docs/specifications.html 

ALOHA WidowX-250 6DOF

ALOHA ViperX-300 6DOF


Waveshare RoArm

ROBOTIS Open Manipulator-P

ROBOTIS Open Manipulator-X

https://emanual.robotis.com/docs/en/platform/openmanipulator_x/specification/#specification 

SO-ARM100

https://github.com/TheRobotStudio/SO-ARM100 

https://github.com/huggingface/lerobot/blob/main/examples/10_use_so100.md 

https://medium.com/@sarohapranav/my-experiences-and-tips-for-creating-a-robotic-so100-arm-3df779a4aae7 

https://github.com/JafarAbdi/ros2_so_arm100 

pince compatible SO-ARM

Cartes de contrôle

OpenCR1.0

https://emanual.robotis.com/docs/en/parts/controller/opencr10/ 

Waveshare Serial Bus Servo Driver Board

 https://www.waveshare.com/wiki/Bus_Servo_Adapter_(A) 

Feetech FE-URT-1 

https://www.feetechrc.com/FE-URT1-C001.html 

AREXX Intelligence Centre

https://seafile.unistra.fr/d/693101e6046d4819a3af/ 

image.png

image.png

Servomoteurs

Dynamixel XM430-W350

https://emanual.robotis.com/docs/en/dxl/x/xm430-w350/ 

Feetech STS3215

https://www.feetechrc.com/en/2020-05-13_56655.html 


SO-ARM100 - Robotique éducative

Pilotage ST3215 depuis un ESP32

https://github.com/sepastian/ESP32_ST3215 

ROS2 avec SO-ARM101

ROS2 et MoveIt2

Installer les paquets ROS2 du SO-ARM100 :

mkdir -p ~/ws_so_arm100/src
cd ~/ws_so_arm100/src
git clone --recurse-submodules https://github.com/JafarAbdi/ros2_so_arm100
cd ~/ws_so_arm100
sudo rosdep init
rosdep update && rosdep install --ignore-src --from-paths src -y
colcon build --symlink-install # dans une VM ajouter --parallel-workers 1
source install/setup.bash
ros2 launch so_arm100_moveit_config demo.launch.py hardware_type:=mock_components # hardware_type:=real for running with hardware

Tester la démo en simulation :

Pilotage des servomoteurs : TTL, RS232, RS485

Modes de contrôle des servomoteurs

Regarder la classification des constructeurs permet de se rendre compte des différentes manières de piloter un servomoteur :

Cela va donc du contrôle PWM jusqu'aux bus et protocoles industriels :

Introduction au contrôle PLC

https://celka.fr/ocw/plc-control/modbus/intro-modbus/intro/ 

Protocoles de communication

Dynamixel :

Feetech :

https://esp32io.com/tutorials/esp32-rs485 

Transmission TTL et protocole RS485

Transmission série

Avantages

Inconvénients

Transmission série synchrone

 

Transmission série asynchrone

Exemple : port série RS232 du PC

 

Exemple d’un adapteur FTDI USB-RS232

image.pngimage.png

Transmission série asynchrone TTL

Exemple de trame série (TTL)

‘1’ logique = +5V

‘0’ logique = 0V

image.png

Transmission série asynchrone RS485 vs RS232

 

image.png

Transmission série asynchrone RS485

image.png

Liaisons multipoints

image.png

Penser aux résistances de Terminaison de 120 Ω au début et à la fin de la liaison RS485.

image.png

image.png

Half Duplex


Définition

Exemple

image.png

Topologie : Bus

Principe

image.png

 

image.png

Avantages

Inconvénients

Exemples

Source : Cours IUT Haguenau - Département GEII - Automatisme Spé. 4 - Réseaux Locaux Industriels - Philippe Celka, le 28.02.2022

Philippe Celka Copyright © 2025 CC Attribution-Non Commercial-Share Alike 4.0 International

Introduction à Modbus

Protocole Modbus

logo Modbus

Introduction

Modbus est un protocole de communication non propriétaire créé par Modicon en 1979. Les spécifications du protocole sont données librement sur le site de la Modbus Organization. Ce consortium a été créé par Schneider suite au rachat de Modicon en 1997 pour promouvoir Mobdus auprès des fabricants et utilisateurs.

Modbus est très populaire dans les environnement industriels car c’est un protocole simple, facile à intégrer, efficace, fiable, ouvert et royalty-free ! Vous pouvez très facilement intégrer Modbus dans vos projets à base d’ESP32, Raspberry, STM32 …

Le protocole Modbus était à l’origine un protocole sur bus série (Modbus RTU). Il a évolué pour s’intégrer aux technologies TCP/IP quand Ethernet est monté en puissance. On le retrouve dans les domaines de:

C’est une couche applicative (niveau 7 OSI) qui se base sur les liaison séries ou sur les trames Ethernet et les couches TCP/IP.

Stack de communication Modbus :

Modbus Stack

On distingue les différents modes de communication :

Nous débuterons l’analyse du protocole suivant la chronologie avec l’étude du Mobdus RTU (Remote Terminal Unit) sur liaison série.

Modbus RTU

Principe du protocole Master / Slave utilisé en Modbus Serial


La terminologie Master / Slave est remise en cause ces dernières années dans la communauté des développeurs et l’on évite de l’utiliser sur de nouveaux projets. Comme ces termes sont utilisés dans les spécifications officielles “Modbus Serial”, je continuerai des les employer sur cet exemple par cohérence avec les documentations.

Principe de fonctionnement :

Le Master peut initier une transaction avec le Slave suivant deux modes :

Modbus RTU unicast

Le fait d’interroger les Slaves les uns à la suite des autres consiste à effectuer du “Polling”.

Description du protocole

Le protocole Modbus définie un Protocol Data Unit (PDU) indépendant des couches de communication. Il s’agit de la structure du message de base :


Modbus PDU

Function Code représente le type d’ordre (lire, écrire) et les datas sont les paramètres de l’ordre (lire 4 registres mémoire depuis l’adresse 0x3214 par exemple).

Empaqueter le protocole Modbus sur un bus série ou Ethernet nécessite des champs additionels au PDU.

Modbus RTU PDU

 

Sur une liaison Modbus série, l’Address field contient uniquement l’adresse du Slave.

Le champ CRC contient un code de contrôle d’intégrité de message pour détecter les erreurs de transmission.

Les règles d’adressage Modbus

Les adresses des appareils (devices) Modbus sont codés sur 1 octet (8 bits). Il y a donc 256 adresses possibles.

0 From 1 to 247 From 248 to 255
Broadcast address Slave individual addresses Reserved

Les types de données

Il y a deux types de données en Modbus, le bit et le Word (16 bits).

  Type d’objet Accès Exemple
Discrete Input bit Read-Only Entrée TOR, fin de course, contact auxilliaire de disjoncteurs, …
Coil bit Read-Write Sortie TOR, bit interne, RAZ d’un compteur d’énergie, …
Input Register Word (16 bits) Read-Only Entrée analogique, lecture d’un capteur, …
Holding Register Word (16 bits) Read-Write Sortie analogique, variable de programme (ex : temporisation, opérande d’un calcul,…) Valeur de paramétrage d’un équipement (ex: consigne de vitesse d’un variateur de fréquence,…)

Un registre est codé sur 16 bits. Holding Register correspond ainsi à 16 Coil en mode Read-Write tandis que Input Register correspond à 16 entrées que l’on peut seulement acceder en lecture (Read-only).

Rappel :

Les fonctions Modbus

Les “Function Code” correspondent aux types d’ordres, lire ou écrire par exemple, ainsi que le type d’accès (accès au niveau bit ou au niveau registre de 16 bits). Les fonctions sont identifiées par un code sur 8 bits qui peut être représenté en décimal ou en hexa.

Bit access

Code Hex Nom de fonction Commentaire
02 0x02 Read Discrete Inputs Physical Discrete Inputs
01 0x01 Read Coils Internal Bits or Physical coils
05 0x05 Write Single Coil Internal Bits or Physical coils
15 0x0F Write Multiple Coils Internal Bits or Physical coils

16-bit access (register)

Code Hex Nom de fonction Commentaire
04 0x04 Read Input Register Physical Input Registers
03 0x03 Read Holding Registers Internal Registers or Physical Output Registers
06 0x06 Write Single Register Internal Registers or Physical Output Registers
16 0x10 Write Multiple Registers Internal Registers or Physical Output Registers

Les tableaux ci-dessus ne sont pas exhaustif, il y a également des Function Code pour réaliser du diagnostique. Il faut savoir que les fabricants de matériel Modbus n’intègre pas forcément toutes les fonctions possibles. Les fonctions Modbus disponibles sont données dans la documentation technique du constructeur.

Description d’une trame Modbus série

Une communication Modbus série est définie par

Classiquement, en Modbus RTU, c’est la parité paire (Even) qui est utilisée. Si l’on choisit de ne pas implémenter le contrôle de parité (None) il faut placer 2 bits de stop.

Une trame Modbus RTU est composée a minima de 4 octets et au maximun de 256 octets. Chaque octet (byte) qui compose une trame Modbus est codé de la manière suivante :

Modbus RTU frame

 

Une trame Modbus RTU

Une trame Modbus RTU est ainsi composée :

Modbus RTU Frame

La taille maximale d’une trame Modbus RTU est de 256 bytes.

Le CRC est calculé avec l’algo CRC-16-MODBUS.

Acquisition d’une trame Modbus de type request

Scope Frame Modbus RTU

Le décodage de trame Modbus intégré donne au format hexa la trame suivante :

01 03 00 01 00 02 95 CB

On en déduit :

Pour Data, suivant les caractéristiques de la fonction 03 Read Holding Register, les deux premiers bytes 00 01 corresponde à l’adresse de registre de départ et les deux suivants 00 02 correspondent aux nombre de registres que l’on souhaite lire à partir du registre de départ.

En résumé: la trame Modbus RTU suivante effectue la requête suivante -> Au Slave 01, donne la valeur des 00 02 premiers registres à partir de l’adresse mémoire 00 01.

Branchement Modbus RTU en configuration 2 Wire

Le branchement Modbus RTU classique est le “2 Wire” en conformité avec le standard RS-485. Sur un “2W-Bus”, seul un driver à la fois a la possibilité de transmettre un message.

Modbus Two 2 Wire

On parle de topologie 2 fils (2-Wire), mais on se rend compte sur le schéma, que finalement, 3 fils sont utilisés avec la masse (Common).

Modbus Name RS-485 Name Autre Nom Description
D1 B D+ ou Data+ Transceiver Terminal 1 (V1>V0 for binary 1 [OFF] state)
D0 A D- ou Data- Transceiver Terminal 0 (V0>V1 for binary 0 [ON] state)
Common C 0v ou GND Commun, Masse (0V)

En RS-485, à 9600 bit/s sur une paire torsadée en AWG26, on arrive à une longueur de bus maximale de 1000 m!

Les résistances de polarisation (RPull−Up et RPull−Down) permettent de limiter le bruit sur le bus quand il n’y a pas de communication. Les valeurs de ces résistances sont comprises entre 450Ω et 650Ω.

Remarques : Il existe également des configurations de branchement en 4 fils (4-Wire) mais c’est rare.

Connectique Modbus RTU

En Modbus RTU RS-485, trois types de connecteurs connecteurs sont souvent utilisés :

Bornier à visser :

Sur le Wago Controller 100, la connexion se fait par un bornier automatique et utilise les abréviations D+ (D1 ou B) et D- (D0 ou A). L’abréviation GND est utilisée pour le commun (0V) et SH (Shield) pour une connexion au blindage.

Modbus Wago Controller 100

Connecteur DB9 :

L’automate PFC200 de chez Wago utilise une connectique DB9 qui permet de réaliser des liaisons RS-485 ou RS232. Pour le Modbus RTU, c’est la RS-485 qui est classiquement utilisée.

PFC200 WAGO Connecteur DB9
Modbus Wago PFC200
Modbus Wago DB9

La documentation constructeur donne les informations suivantes pour la connectique DB9 du PFC200 en mode RS485.

Contact Signal RS-485 Description
1 NC Not assigned
2 NC Not assigned
3 A (Tx/Rx+) Transmitt/receive Data+
4 NC Not assigned
5 FB_GND Ground
6 FB_5V Power Supply
7 NC Not assigned
8 B (Tx/Rx-) Transmitt/receive Data-
9 NC Not assigned
Housing Shield Shield

On se rend compte que Wago ne respecte pas la norme Modbus dans ce produit ! Ils appellent A -> Data + et B -> Data - qui correspond à la dénomination Profibus de Siemens ! Si votre communication ne fonctionne pas, il suffit parfois d’inverser les fils A-B car le fabricant a mélangé la norme.

Connecteur RJ45


Les fabricants utilisent aussi parfois un connecteur RJ45 pour les liaison RS-485 ! L’erreur est de croire que l’on peut connecter ce type d’appareils sur un switch ou sur le port RJ45 de votre PC. NE LE FAITES PAS !

Bien qu’il s’agisse d’un connecteur RJ45, il s’agit d’une liaison série qui est transportée et il faut donc l’associer à une interface série et non au port RJ45 de votre PC ou de votre switch ! Les fabricants adoptent parfois la connectique RJ45 car les câbles sont peu chers avec un branchement qui est facile et rapide.

Wago Current Sensor Modbus RTU

La documentation Wago donne l’association des broches du connecteur RJ45 :

Pin Function
1 Ub
2 Ub
3 n.c.
4 A (Data+)
5 B (Data-)
6 n.c.
7 GND
8 GND

Toujours la même erreur chez Wago. Ils appellent A -> Data+ et B -> Data- qui correspond à la dénomination Profibus de Siemens.

Connexion RJ45 et DB9 selon spécifications Modbus

Modbus DB9 RJ45
Pin on RJ45 Pin on DB9 Level of requirement Modbus RS-485 Description
3 3 optional PMC - Port Mode Control
4 5 required D1 B Transceiver terminal 1, V1 Voltage (V1>V0 for binary 1 [OFF] state)
5 9 required D0 A Transceiver terminal 0, V0 Voltage (V0>V1 for binary 0 [ON] state)
7 2 recommended VP - Positive 5..24 Vdc Power Supply
8 1 required Common C Signal and Power Supply Common

On se rend compte que Wago n’a pas suivi les recommandations de câblage fixées par la Modbus Organization, de nombreux fabricants font de même. Quand il s’agit d’appareillages d’un même constructeur, cela ne pose pas de soucis, par contre, il faut parfois inverser les signaux A et B quand on mélange les appareillages de fabricants différents sur un même bus Modbus RTU. En Modbus TCP, comme c’est sur du câble Ethernet, on n’a pas ce problème.

Exemple : Modbus RTU avec un capteur de Température et Humidité

Dans cet exemple, je vais connecter un capteur de température et d’humidité PKTH100B-CZ1 qui communique en Modbus RTU avec mon ordinateur portable.

Pour que le PC portable puisse communiquer en RS-485, je lui ajoute un convertisseur FTDI USB-RS485, ainsi qu’un Oscilloscope pour visualiser les trames Modbus-RTU (côté didactique)

Capteur PKTH100B-CZ1 FTDI USB-RS485 Oscilloscope
PKTH100-1 Sensor
FTDI USB RS485
Siglent SDS1202X-E

L’analyse de la documentation du câble FTDI USB-RS485 nous donne les informations suivantes :

Les câble USB-RS485

FTDI USB-RS485 colors
Signal Couleur de fil
GND Noir
(A) Data - Jaune
+5V Rouge
R de 120Ω pin 1 Brun
(B) Data + Orange
R de 120Ω pin 2 Vert

Le capteur

PKTH100-1 Sensor
Terminals number 1 2 3 4
Identifying GND VCC B A
Description Power- Power+ RS485- RS485+

On remarque que sur la documentation du capteur, le signal A est nommé RS485+ tandis que sur la document du convertisseur USB-RS485, le signal A est nommé Data - …

On va rester pragramatique et brancher le fil A (jaune) sur le bornier A (4) du capteur et le fil B (Orange) du convertisseur vers la borne B (3) du capteur. Si jamais cela ne fonctionne pas, il suffira d’inverser ;)

Les masses devant être communes, on branchera le fil GND (noir) du convertisseur à la borne GND (1) du capteur.

Pour alimenter le capteur, j’utilise une alimentation de laboratoire de 24Vdc. Pareil, je brancherai le +24Vdc de l’alimentation à la borne VCC (2) du capteur et le 0V de l’alimentation à la borne GND (1) du capteur.

Pour les résistances de terminaison de 120Ω, je fais le choix de ne pas les placer dans un premier temps car la longueur de bus est très faible.

La manipulation

Manipulation Modbus Capteur Temperature

La documentation (en chinois) indique les paramètres suivants :

  • Vitesse de transmission : 9600 bit/s
  • 8 bits de données
  • Parity : None
  • 1 Stop bit (non respect de la norme)
  • Slave Address (factory) : 1

La document indique également que la requête à envoyer est une fonction de type 03 Read Holding Resgister à l’adresse de Slave 1 et que l’on lit à partir du registre mémoire 0 un nombre de 2 registres.

La trame à envoyer avec le CRC est la suivante : 01 03 00 00 00 02 C4 0B

J’utilise le logiciel QModMaster pour générer facilement la trame et et bien sur, cela ne fonctionne pas :(

On va essayer d’inverser les fils A et B -> boum, ça fonctionne…bref

Les différentes étapes de la configuration de qModMaster

On le numéro du port Com utilisé par le convertisseur USB-RS485 avec le gestionnaire de périphériques Windows. On remarque que dans mon cas, c’est le COM5 qui lui a été attribué. Cela nous permet de paramétrer la liaison série RTU dans QModMaster avec le bon numéro de Com et l’on saisie également les paramètres de liaison du capteur de température (9600 bit/s 8bits de données 1 bit de stop et parity None)

Gestionnaire de périphériques Config Serial dans QModMaster

Dans QModMaster, je choisis le Mode RTU, le Slave Address à 1, le Function Code à 0x03 pour Read Holding Register, le Start Address à 0 et Number of Coils (Registers) à 2.

Dans le Bus Monitor, on remarque que la trame de request vaut : 01 03 00 00 00 02 C4 0B -> ce qui était demandé par la doc, donc on est OK !

La trame de réponse (reply) du capteurs vaut : 01 03 04 01 28 02 22 FA BE

QModMaster Bus Monitor

Le décodage du résultat est donné directement par QModMaster:

  • Le premier registre vaut : 296 en décimal
  • Le second registre vaut : 546 en décimal

La documentation du capteur indique que la valeur du premier registre correspond à la température multipliée par 10. On en déduit qu’il fait 29,6°C en cette journée d’août -> c’est OK

L’humidité multipliée par 10 est dans le second registre. On en déduit que l’humidité relative Hr=54.6% ce qui est conforme.

Méthode de décodage à partir de la trame de réponse

La trame de réponse (reply) du capteurs vaut : 01 03 04 01 28 02 22 FA BE . On peut décoder le contenu de la manière suivante :

  • 01: correspond à l’adresse du capteuur qui donne la réponse
  • 03: indique qu’il répond à une réquête de type 03 Read Holding Register
  • 04: c’est la valeur de la fonction 03 + 1 pour dire que tout c’est bien passé !
  • 01 28: c’est la valeur en hexa du contenu du premier registre avec 01 l’octet de poids fort et 28 l’octet de poids faible. Converti en décimal, on obtient 296
  • 02 22: correspond à la valeur en hexa du second registre. Converti en décimal, on obtient 546.
  • FA BE: correspond au CRC de la trame de réponse.

Capture des trames Modbus RTU avec l’oscilloscope

On peut observer la trame de request générée par QModMaster qui vaut 01 03 00 00 00 02 C4 0B

Modbus Oscilloscope Frame

 

Et la trame de réponse du capteur qui vaut 01 03 04 01 28 02 22 FA BE

Modbus Oscilloscope Frame

Source https://celka.fr/ocw/plc-control/modbus/intro-modbus/intro/ 

Philippe Celka Copyright © 2025 CC Attribution-Non Commercial-Share Alike 4.0 International