La carte RDK X5, développée par D-Robotics, est une plateforme puissante et compacte compatible avec l’IA, conçue pour les applications robotiques et basées sur la vision. Basée sur un Sunrise 5 développé par D-Robotics et équipée d’une caméra stéréo, elle est préchargée avec ROS 2 et une suite d’outils qui la rendent idéale pour le prototypage de fonctionnalités robotiques avancées, du simple streaming d’images à la détection faciale complexe et à la reconstruction 3D.

Dans cet article, je partage mon expérience pratique de la configuration de la carte, du test de différentes configurations de caméra et de l’exécution de la détection des points de repère faciaux en temps réel. L’objectif est de fournir un guide pratique aux développeurs, aux fabricants et aux éducateurs qui souhaitent explorer le potentiel de la carte dans les environnements ROS 2.

Carte RDK X5 de D-Robotics avec de l’IA embarquée

Présentation de la carte

La carte RDKX5 est livrée dans une boîte de belle apparence
A l’arrière de la boîte on trouve les caractéristiques de la carte.
Le format est proche de celui du Raspberry Pi. On note quand même un vrai port HDMI et une prise jack 3,5 mm en bout de carte, là où on trouve normalement le port PCIe sur le Pi 5.

Le processeur embarqué est le Sunrise 5 : c’est le cœur – ou plutôt le cerveau – de la carte D‑Robotics RDK X5 :

• microprocesseur : 8 cœurs ARM Cortex‑A55 (~1,5 GHz) – idéal pour Linux et pour piloter l’IA embarquée.
• GPU : environ 32 GFLOPS, avec support HW des formats H.265/H.264…
• BPU (AI chip) : jusqu’à 10 TOPS de puissance de calcul IA en local – parfait pour l’inférence de modèles comme YOLO, Transformer, RWKV, stéréo-perception…

Le BPU (Brain Processing Unit) est une unité spécialisée conçue spécifiquement pour traiter des modèles d’intelligence artificielle, particulièrement pour l’inférence de réseaux neuronaux profonds directement sur la carte électronique, sans passer par le cloud ou des ordinateurs externes.

Comment ça marche ?

Le BPU est optimisé pour les calculs matriciels et tensoriels massifs, typiques de l’IA :

• Calcul parallèle massif : Capable d’exécuter simultanément des milliers d’opérations matricielles.
• Efficacité énergétique : Beaucoup plus efficace que d’utiliser un CPU ou un GPU classique pour ce genre de tâches, ce qui est essentiel pour les applications embarquées autonomes.
• Accélération matérielle : Inclut souvent des unités spécialisées pour les réseaux neuronaux comme les convolutions, la normalisation et les fonctions d’activation.

Que permet concrètement le BPU ?

• Vision artificielle en temps réel : Reconnaissance d’objets, segmentation d’image, détection de mouvements, etc.
• Traitement audio : Reconnaissance vocale, détection d’événements sonores (par exemple, identifier la voix humaine parmi d’autres bruits).
• Robotique autonome : Navigation, détection et évitement d’obstacles, reconnaissance d’environnement en temps réel.
• Edge computing : Tout est traité localement, garantissant confidentialité, latence réduite, et fonctionnement même sans connexion internet.

Comparaison rapide avec CPU et GPU :

Aspect	CPU	GPU	BPU
Polyvalence générale	✅✅✅	✅✅	✅
Performances IA spécifiques	✅	✅✅✅	✅✅✅✅
Efficacité énergétique IA	✅	✅✅	✅✅✅✅
Latence	Moyenne	Faible	Très faible

Pourquoi choisir un BPU comme celui du Sunrise 5 ?

Le Sunrise 5 de D-Robotics, avec ses 10 TOPS (Tera Operations per Second), permet de déployer directement des modèles IA complexes comme YOLO, Transformer, ou RWKV sur la carte RDK X5. Ça signifie :

• Des robots ou systèmes intelligents réactifs, capables d’analyser leur environnement à une vitesse impressionnante.
• Une consommation maîtrisée : idéal pour du matériel embarqué ou autonome sur batterie.
• Moins de dépendance vis-à-vis du cloud : essentiel pour la confidentialité et la réactivité en temps réel.Un BPU comme celui du Sunrise 5 c’est une petite centrale de calcul dédiée à l’IA directement embarquée sur un appareil, un robot. Ça change la donne, surtout dans tes projets de robotique et d’IA embarquée !

La sortie HDMI et le jack audio

Vue d’ensemble de la carte et des GPIO.

Le radiateur est en aluminium épais de plusieurs millimètres. Il suffit pour dissiper la chaleur du processeur.

Il faut équiper le processeur d’un bloc de pâte thermique avant de poser le radiateur

La carte que j’ai reçue possède une RAM 8 Go LPDDR4 (existe aussi en 4 Go). L’OS est sur une carte micro-SD.

Connectivité :

• Ethernet Gigabit avec PoE
• Wi‑Fi 6 + Bluetooth 5.4
• CAN‑FD
• 4× USB 3.0 (hôte), 1× USB 2.0 (device, 1× UART)
• Batterie pour RTC

I/O multimédia :

• HDMI 1080p60, MIPI‑DSI (écran),
• 2× MIPI‑CSI caméras (stéréo possible),
• Jack audio 3,5 mm,
• 28 GPIO (SPI, I²C, UART, PWM…) via header 40 broches

Refroidissement :
Plage d’utilisation : –20 °C à +60 °C. Le DIE peut grimper à 105 °C avant d’agir.
Recommandation : un petit dissipateur ou boîtier ventilé est un plus pour les usages intensifs.

La caméra stéréo

La boîte de la caméra stéréo

Caractéristiques de la caméra : 2x 2Mpx, 1920×1080 px et un écartement de 7cm des 2 objectifs

La caméra est livrée avec 2 nappes (câbles plats)
La connexion des câbles sur la caméra est classique : lever le verrou, enfoncer le câble bien perpendiculairement et à fond, rabattre le verrou.

Gros plan sur les connecteurs de la caméra

Connexion d’un câble sur une prise CSI de la carte RDK X5. Repérez le sens de montage…

Les deux prises sont connectées, l’ensemble est prêt à fonctionner…

La caméra stéréo devant la carte RDK X5

 

⚠️ À propos des mises à jour système

Lorsqu’on travaille avec ROS 2, il est important de maintenir à jour la liste des paquets disponibles sur le système.
Pour cela, il est conseillé de faire régulièrement :

Cela permet de récupérer les dernières informations sur les versions disponibles sans rien modifier sur le système.

---

En revanche, il est déconseillé de faire une mise à jour complète (sudo apt upgrade) sans précaution, surtout sur une machine utilisée pour des projets ROS 2.
Une mise à jour globale peut :

• casser des dépendances installées pour ROS 2,

• modifier des librairies sensibles,

• entraîner des incompatibilités avec des packages existants.

---

En résumé :

• ✅ Faites sudo apt update pour rafraîchir la liste des paquets.

• ⚠️ Évitez sudo apt upgrade tant que votre environnement est fonctionnel et que votre projet est en cours.

Vous pourrez planifier une mise à jour complète plus tard, une fois votre travail terminé et sauvegardé.

Installation du système d’exploitation

On va récupérer l’OS sur le site de D-robotics et utiliser la procédure présentée sur la page de l’installation de la RDK X5. Allez sur la page de téléchargement des OS de la RDK X5.

J’ai utilisé la dernière version disponible à la date de la rédaction de cet article (avril 2025), la version 3.1.1, ouvrez ce dossier

et téléchargez la version de l’OS qui vous intéresse. J’ai opté pour la version Desktop, un MD5 est disponible pour vérifier l’intégrité de l’archive téléchargée.

Une fois l’OS récupéré, il faut décompresser l’archive .xz pour récupérer l’image avant de la graver sur une carte SD.

 

 

D-robotics recommande BalenaEtcher, j’avais Rufus installé sur la machine et c’est ce que j’ai utilisé avec une carte 128Go toute neuve. Lancez Rufus, sélectionnez l’OS que vous voulez installer sur la carte et lancez le transfert.

 

 

 

 

Il n’y a plus qu’à glisser la carte SD à son emplacement sous la RDK X5, à connecter la prise HDMI, un clavier et une souris et finalement à connecter une alim 5v sur le port USB-C. Patientez quelques secondes et…

Votre écran affiche la page d’accueil de l’OS préparé par D-robotics pour sa carte RDK X5.

Configuration du système d’exploitation de le carte RDK X5

 

en SSH id = sunrise  pwd = sunrise

• Locales   fr_FR.UTF-8 UTF-8
• Time zone > Europe > Paris
• Keyboard > Generic 105 keys > French > French AZERTY

Sortez et rebootez la carte.

Le clavier est repassé en QWERTY, j ai modifié dans le menu Applications > Gestionnaire de paramètres > Session et démarrage > Application Autostart :

Les menus sont bien en français mais le clavier est toujours en QWERTY j ai essayé le clavier French (le premier de la liste et cette fois c est OK. On va installer VNC pour travailler depuis le PC (et je pourrai faire des copies d’écran pour illustrer la suite de cet article)

On va lancer VNC Server (présent dans l’OS que j’ai installé)

vncserver

Il faut entrer un mot de passe (j’ai mis 123456, et je n’ai pas mis de MDP pour le view only (voir seulement). La carte RDK est en 192.168.127.10 255.255.255.0 en statique. On va la passer en adresse dynamique pour qu’elle prenne une adresse IP dans le réseau local sur la box Internet.

On ouvre le fichier interfaces

sudo nano /etc/network/interfaces

et effectivement eth0 est en inet static à l’adresse 192.168.127.10

Remplacer la rubrique eth0 par :

auto eth0
iface eth0 inet dhcp

Puis redémarrer la carte

sudo reboot

et la carte est cette fois en 192.168.1.30, dans le réseau de la box…

Connecter la carte en VNC

Créer un fichier x11vnc.service

sudo nano /etc/systemd/system/x11vnc.service

Coller ceci dans le fichier

Démarrer le service

sudo systemctl daemon-reload

Activer le service pour qu il démarre automatiquement

sudo systemctl enable x11vnc.service

Enfin démarrer le service

sudo systemctl start x11vnc.service

On va tester le VNC : redémarrez la carte

sudo reboot

A partir de là, le server VNC se lance au démarrage, ce que vous pouvez vérifier en vous connectant depuis un PC sur l’adresse de la carte RDK X5 :

A partir de là vous pourrez accéder à votre carte via un PC et VNC Viewer, et pour ma part je pourrai faire des copies d’écrans (screenshots) de meilleure qualité que les photos précédentes 😉

Vérification de l’installation de ROS2

Présentation rapide de ROS 2 et des topics

ROS 2 (Robot Operating System 2) est un ensemble d’outils, de librairies et de conventions qui permettent de développer des applications robotiques de manière modulaire.
Au cœur de ROS 2, les nœuds (programmes indépendants) communiquent entre eux grâce à des topics.

Un topic est un canal de communication sur lequel :

• des nœuds peuvent publier des messages,
• et d’autres nœuds peuvent s’abonner pour recevoir ces messages.

Cette architecture permet par exemple :

• à une caméra de publier des images sur un topic,
• et à un autre programme (comme un affichage ou un traitement d’image) de récupérer ces images pour les utiliser.

Chaque message échangé dans ROS 2 a un type (par exemple une image, un nuage de points, un texte, etc.), ce qui permet de structurer les données de manière fiable.

Dans notre cas concret :

• Le nœud cam2image publie des images sur le topic /image.
• Le plugin rqt_image_view s’abonne à ce topic pour afficher les images en direct.

Cette communication asynchrone et découplée est l’un des grands atouts de ROS 2 pour construire des systèmes complexes, flexibles et évolutifs.

ROS 2 et MQTT : un principe similaire

Si vous avez déjà utilisé MQTT dans des projets d’objets connectés, la communication entre nœuds dans ROS 2 vous semblera très familière.

En effet, ROS 2 utilise aussi un modèle de publication/abonnement :

• Un nœud publie des données sur un topic,
• Un autre nœud s’abonne à ce topic pour recevoir ces données.

La grande différence est que ROS 2 ne nécessite pas de serveur central (pas de broker comme Mosquitto en MQTT).
Grâce au système DDS (Data Distribution Service), les nœuds communiquent directement entre eux, en pair à pair.

En résumé :

• ROS 2 ➔ publication/abonnement direct entre applications robotiques
• MQTT ➔ publication/abonnement via un serveur (broker) pour des capteurs ou objets connectés
• Tous deux utilisent des topics hiérarchiques pour organiser les échanges.

Ce modèle permet à ROS 2 de gérer efficacement des flux complexes comme des images de caméras, des nuages de points 3D ou des commandes de robots, en conservant une grande souplesse dans la communication.

« Sourcer » ROS 2 : Qu’est-ce que ça veut dire ?

Quand vous installez ROS 2 (c’est déjà fait dans l’image fournie par D-Robotics), les programmes et bibliothèques sont copiés dans le dossier /opt/ros/humble/.
Mais par défaut, le terminal qu’on ouvre ne sait pas que ROS 2 existe.

« Sourcer » un fichier (comme setup.bash) signifie lire ce fichier et appliquer les réglages qu’il contient au terminal actuel. Quand on fait

source /opt/ros/humble/setup.bash

on demande au terminal de :

• Ajouter ROS 2 dans le PATH (pour qu’il trouve les commandes ros2, ros2 run, etc.)
• Configurer certaines variables d’environnement (par exemple ROS_DISTRO=humble).
• Mettre à disposition toutes les bibliothèques nécessaires pour ROS 2.

Exemple

Avant de sourcer :

ros2
> command not found

Après avoir sourcé :

ros2
> (l’aide de ros2 apparait)

Le terminal est maintenant prêt à utiliser ROS2.

Cet ajout est temporaire

Quand on « source », ça ne dure que pour LE terminal actuel :
==>
Si on ferme le terminal, c’est oublié.
Si on ouvre un nouveau terminal, il faut refaire source /opt/ros/humble/setup.bash.

À quoi sert exactement le fichier setup.bash ?

C’est un script shell qui :

• Ajoute /opt/ros/humble/bin dans la variable PATH
• Configure d’autres variables nécessaires à ROS 2 (chemins vers les modules, les packages, etc.)

C’est en fait l’équivalent d’un « mode d’emploi » que le terminal lit pour préparer l’environnement ROS 2. C’est irréversible, on ne peut pas dé-sourcer ROS2, la fermeture du terminal permet de libérer ce qui a été modifié pour ce terminal.

Automatiser l’accès à ROS2 (facultatif)

Si vous souhaitez éviter de refaire la commande source à chaque fois, vous pouvez ajouter l’activation automatique dans votre fichier ~/.bashrc :

echo « source /opt/ros/humble/setup.bash » >> ~/.bashrc

Puis rechargez la configuration :

source  ~/.bashrc

Ainsi, chaque fois que vous ouvrirez un terminal, ROS 2 sera prêt automatiquement !

⚠️ Attention : si vous travaillez avec plusieurs versions de ROS 2 ou si vous n’utilisez pas toujours ROS, il est préférable de faire le source manuellement pour éviter des conflits d’environnement.

Tester rapidement une caméra USB sur Linux

Avant de connecter la caméra stéréo au système, il est important de valider que la capture et l’affichage d’images fonctionnent correctement dans ROS 2.
Pour cela, nous allons commencer par utiliser une caméra USB classique, plus simple à configurer, afin de vérifier la chaîne complète d’acquisition, de publication et de visualisation d’images.
Cette étape permet de s’assurer que le système est prêt avant d’intégrer du matériel plus spécifique comme la caméra stéréo.

Vérification de la caméra USB

Commencez par brancher la caméra sur un port USB, puis dans un terminal, tapez :

ls /dev/video*

Vous devriez voir apparaître un ou plusieurs périphériques, comme /dev/video0, /dev/video1, etc.

Ensuite, pour lister précisément les caméras détectées :

v4l2-ctl –list-devices

(le paquet v4l-utils doit être installé, sinon installez-le avec sudo apt install v4l-utils)

Cela vous indiquera les caméras branchées ainsi que leur correspondance avec les /dev/videoX.

Test rapide du flux vidéo

Pour vérifier que la caméra fonctionne correctement, vous pouvez utiliser l’outil ffplay :

ffplay /dev/video0

Cela ouvrira une fenêtre avec le flux vidéo en direct.
Si ffplay n’est pas installé, vous pouvez l’ajouter avec :

sudo apt update
sudo apt install ffmpeg

Exemple de résultat

✅ Si vous vous voyez à l’écran, la caméra est opérationnelle et prête à être utilisée dans vos projets ROS 2 !

Pour publier les images de la caméra USB dans ROS 2, commencez par installer le package image_tools :

sudo apt install ros-humble-image-tools

Ce package fournit notamment la commande suivante :

ros2 run image_tools cam2image

qui publie les images sur le topic /image.

Utiliser la caméra dans ROS 2

🔵 Important : avant toute commande ROS 2 dans un terminal, n’oubliez pas de sourcer l’environnement :

source /opt/ros/humble/setup.bash

Ensuite, on peut utiliser le package image_tools, qui permet de capturer et publier un flux d’image sur un topic ROS :

ros2 run image_tools cam2image

À ce moment-là, vous devriez voir défiler dans le terminal :

[INFO] [cam2image]: Publishing image #1
[INFO] [cam2image]: Publishing image #2
[INFO] [cam2image]: Publishing image #3
…

Cela indique que les images de la caméra sont publiées sur le topic /image.

Afficher le flux vidéo sous ROS 2 avec RQT

Pour visualiser les images dans un environnement graphique :

Installer rqt_image_view  :
sudo apt install ros-humble-rqt-image-view

Dans un nouveau terminal sourcer ROS 2 :

source /opt/ros/humble/setup.bash

Lancer RQT :

rqt

Dans la fenêtre RQT :

Aller dans Plugins → Visualization → Image View
Sélectionner le topic /image dans le menu déroulant

À ce moment-là, l’image de la caméra devrait apparaître en direct !

📌 Note sur l’affichage distant (VNC)

Lorsque vous utilisez une connexion VNC pour voir l’écran de la RDK X5, vous pouvez constater une latence de 1 à 3 secondes sur la vidéo.
C’est un comportement normal dû à :

• la capture d’écran,
• la compression,
• la transmission réseau,
• et l’affichage sur votre machine.

👉 Sur un écran HDMI branché directement à la RDK X5, l’affichage de la caméra est immédiat, sans latence.

✅ À ce stade, nous avons donc validé le fonctionnement d’une caméra USB simple sous ROS 2

Détection de visage et points caractéristiques (landmarks) sous ROS 2 et OpenCV

Pour ce projet utilisant la RDK X5, nous avons testé la possibilité de détecter des visages et de placer automatiquement des points caractéristiques sur les yeux, le nez, la bouche et le contour du visage.
C’est une étape clé avant d’aller vers des traitements plus avancés comme le suivi de visage ou la création de modèles 3D.

J’ai choisi d’utiliser OpenCV pour commencer, car il est déjà disponible sur la distribution Ubuntu 22.04 de la RDK X5.

OpenCV déjà disponible

Sur la RDK X5, OpenCV est préinstallé ou disponible directement dans les dépôts officiels Ubuntu.

Pour vérifier ou installer OpenCV :

sudo apt update
sudo apt install python3-opencv

Dans notre cas, OpenCV était déjà installé, en version 4.5.4, ce qui est parfait pour notre projet.

Première approche : détection simple du visage

Nous avons commencé par utiliser les outils intégrés de OpenCV, avec un modèle Haar Cascade de détection de visages.

Un premier script permet :

• de détecter un visage,
• d’encadrer le visage avec un rectangle,
• de placer quelques points approximatifs pour simuler nez et yeux.

Cependant, cette méthode est très simplifiée : les points ne suivent pas exactement la forme du visage.

Script face_detect.py

Aller plus loin : détection avancée avec 68 points

Pour une détection précise des yeux, du nez, de la bouche, des sourcils et de la mâchoire, nous allons utiliser un modèle basé sur dlib.

Tout d’abord, installation de pip (éventuellement déjà installé):

sudo apt install python3-pip

Puis installation de dlib  :

pip3 install dlib

(⚠️ Note : l’installation compile les sources de dlib, cela prend de longues minutes sur la carte RDK X5, soyez patient(e) )

Téléchargement du modèle 68 landmarks
wget http://dlib.net/files/shape_predictor_68_face_landmarks.dat.bz2
bunzip2 shape_predictor_68_face_landmarks.dat.bz2

Ce fichier est utilisé pour prédire précisément la position des points caractéristiques du visage.

Attention :
Le fichier .dat doit être placé dans le même dossier que votre script Python pour que la détection fonctionne correctement. Sinon, il faudra indiquer le chemin complet du fichier dans votre script.

Script Python pour afficher les 68 points du visage

Une fois l’environnement prêt, nous avons utilisé ce script pour détecter le visage et afficher les 68 points :

face_landmarks_68.py

Résultat
Lorsqu’un visage est détecté, 68 petits points verts apparaissent en direct sur :

• les contours des yeux,
• les sourcils,
• le nez,
• la bouche,
• la mâchoire.

L’affichage est fluide et suit le mouvement du visage sans problème.

Remarque
Même si nous avons ici utilisé OpenCV + dlib sans ROS 2 directement pour cette première phase, le but est ensuite d’intégrer ce flux d’informations dans un nœud ROS 2 pour traiter les données en robotique ou en réalité augmentée.

On constate une certaine latence sur l’écran HDMI :
📌 Note sur la performance :
Lors de la détection des 68 points faciaux en temps réel, une latence peut apparaître même sur un affichage HDMI direct.
Cela est dû au temps de calcul nécessaire pour détecter le visage et prédire chaque point. Ce phénomène est normal sur des architectures CPU ARM sans accélération matérielle.

Explication rapide du pourquoi il y a de la latence même sur HDMI :

Quand on utilise OpenCV + dlib pour faire la détection de 68 points, ce qui se passe, c’est :

Étape	Temps pris
Capture d’une image depuis la caméra USB	Rapide (~10 ms)
Détection du visage avec dlib (frontal face detector)	Moyen (~30–100 ms selon image)
Prédiction des 68 points (shape predictor)	Moyen à lourd (~50–200 ms selon la vitesse CPU)
Affichage sur l’écran	Rapide

👉 Ce n’est pas l’affichage qui est lent,
c’est le traitement pour détecter et prédire chaque frame qui prend du temps.

🛠️ Solutions pour améliorer un peu :

Modification du programme avec une image plus petite

Ajoutez la ligne de redimensionnement : la latence n’est pas totalement éliminée, mais elle est significativement réduite.

Grâce à cette approche, nous avons validé que la RDK X5 est capable de réaliser en temps réel de la détection faciale avancée, avec une simple caméra USB.
Une base solide pour aller plus loin vers :

• la détection multi-visages,

• la reconnaissance d’émotions,

• ou la reconstruction 3D à partir d’une caméra stéréo !

Nous avons commencé par des outils simples, puis progressivement intégré des techniques plus avancées, tout en restant compatible avec ROS 2

Ahhh oui exact ! 👏 (et tu fais bien de le préciser !)

Ta caméra stéréo est équipée de deux modules caméra, un pour l’œil gauche et un pour l’œil droit, donc :
➡️ Un câble sur CAM1 (réseau/USB)
➡️ Un câble sur CAM2 (UART)

Les deux câbles CSI doivent être branchés pour que la stéréo fonctionne complètement ✅.

Voici donc la version mise à jour de ta rubrique :

Connecter la caméra stéréo à la RDK X5

Objectif : Brancher correctement la caméra stéréo sur la carte RDK X5 pour la calibration et les futures démonstrations.

Matériel nécessaire

• Carte RDK X5
• Caméra stéréo fournie avec la carte
• Deux câbles plats (nappes) pour connexion CSI
• Éventuellement un trépied si montage prévu

Étapes de connexion

• Éteindre la RDK X5 si elle est sous tension.
• Brancher les deux câbles :

• • Premier câble :
    • Connecter la première nappe sur le port CAM1 de la RDK X5 (situé vers les prises réseau et USB).
  • Deuxième câble :
    • Connecter la seconde nappe sur le port CAM2 de la RDK X5 (situé vers le connecteur UART).
  • Orientation :
    • Insérer les câbles avec les contacts métalliques dans la bonne direction (voir photos).
    • Verrouiller les connecteurs en rabattant les barrettes de verrouillage.
  • Brancher l’autre extrémité des câbles à la caméra stéréo, en respectant les mêmes précautions d’orientation et de verrouillage.

• Positionner la caméra :

• • Orienter la caméra à l’horizontale, objectifs vers l’avant.
  • Fixer solidement l’ensemble sur un trépied si besoin.
• Vérification visuelle :

• • Aucun câble ne doit être tordu ou pincé
  • Les connecteurs doivent être bien verrouillés, les parties bleus bien parallèles au connecteur

Connexion et détection de la caméra stéréo sur la RDK X5

Après avoir fixé la caméra stéréo sur son support, j’ai connecté les deux nappes :

• CAM1 (vers les prises Ethernet/USB) ➔ caméra de gauche
• CAM2 (vers la prise UART) ➔ caméra de droite

Premier démarrage de la RDK X5

Après démarrage, je me suis connecté au bureau distant de la carte via VNC.

Dans un premier terminal VNC, je commence par sourcer les environnements ROS 2 et TROS :

Lancement du flux caméra

Toujours dans ce terminal, je lance la démo fournie pour activer la caméra :

Je constate que plusieurs lignes de log apparaissent, notamment :

Ce qui m’indique que la capture MIPI est bien initialisée.

Vérification de la publication sur ROS 2

J’ouvre un deuxième terminal VNC et je sourcer à nouveau :

Je liste les topics :

Le retour est :

Je constate que /image est publié.

Inspection du type de messages sur /image

Je vérifie le type de message :

Retour :

Par curiosité, j’essaye aussi :

Retour :

Le topic publie deux types de messages, ce qui empêche rqt_image_view de fonctionner correctement.

Tentative d’affichage avec rqt_image_view

J’ouvre un troisième terminal VNC et je sourcer :

Je lance manuellement rqt_image_view :

La fenêtre s’ouvre, mais en sélectionnant /image, je n’obtiens qu’un écran gris.

Clonage du dépôt D-Robotics

Afin de préparer la suite, j’ai cloné le dépôt officiel D-Robotics contenant les démos et outils IA :

Mise en place d’un convertisseur

Pour contourner le problème du topic, j’ai créé un petit script Python permettant de :

• Lire les messages CompressedImage
• Les décompresser
• Publier un flux propre sur /image_raw

Emplacement du fichier

J’ai créé le fichier compressed_to_raw.py dans :

Contenu du fichier compressed_to_raw.py

Rendre le script exécutable

Lancement du convertisseur

Dans un nouveau terminal VNC (et toujours après avoir sourcé !) :

Affichage final de l’image

Dans la fenêtre rqt_image_view :

• Cliquer sur la liste déroulante
• Sélectionner /image_raw

✅ L’image de la caméra apparaît enfin correctement.

Conclusion

Cette procédure (réalisée avec l’aide ChatGPT) m’a permis de :

• Connecter la caméra stéréo
• Activer et vérifier la publication du flux
• Contourner le problème des deux types de messages sur /image
• Afficher l’image dans rqt_image_view

La plateforme est maintenant prête pour la calibration stéréo et la reconstruction 3D du visage !

Problèmes rencontrés – Solutions appliquées

 

Conclusion

Un petit pas vers l’autonomie robotique
Bien que l’IA robotique ne soit pas ma spécialité, cette carte est une première passerelle idéale pour moi, maker & électronicien : compacte, puissante et compatible ROS, elle permet de démarrer sans se perdre dans des plateformes surdimensionnées.

Un outil convoité dans la communauté ROS & Ubuntu
En adoptant Ubuntu 22.04 + ROS Humble sur un petit format, on intègres un écosystème riche et open‑source (Gazebo, OpenCV, ROS 2 ★), bien supporté par la communauté et par Canonical

Flexibilité hardware et IA embarquée
L’association d’une carte ARM et d’un BPU autorise l’exécution directe de modèles IA, évitant le recours à des PC lourds, cela devrait favoriser l’arrivée de solutions SBC dans le monde maker .

Ce petit concentré de Linux, ROS et IA est la rampe de lancement idéale pour passer de maker à roboticien – un voyage excitant à concrétiser dès maintenant.

Vous pouvez accéder au dépôt hobot_stereonet (le projet de caméra stéréo de D‑Robotics) :
https://github.com/D-Robotics/hobot_stereonet
Il est en chinois pour le moment (merci Google Trad) et sera bientôt en Anglais.

La docuentation officielle de la carte D-Robotics RDK X5 est ici :
https://developer.d-robotics.cc/en/documentation
et vous trouverez des liens complémentaires dans la rubrisue Sources ci-dessous.

Acheter une carte RDK X5 en France :

Sources

https://github.com/D-Robotics/rdk_model_zoo

https://github.com/D-Robotics

http://www.yahboom.net/study/RDK-X5-Robot

https://d-robotics.github.io/rdk_doc/en/Quick_start/install_os/rdk_x5

https://archive.d-robotics.cc/downloads/en/os_images/rdk_x5/

https://d-robotics.github.io/rdk_doc/en/Quick_start/download/

https://github.com/D-Robotics/hobot_mipi_cam

User Guide

https://d-robotics.github.io/rdk_doc/en/RDK

Examples

Robotics Application Development

RDK X5 Product Manual Schematic