Pratique de l’OriginCar RDK X5 : du flashage de l’image au contrôle ROS 2 à distance

Parcours complet pour l’OriginCar RDK X5 : flashage de l’image et de la carte principale, accès réseau, contrôle du châssis ROS 2, affichage caméra et intégration rosbridge avec un client de bureau.

2 décembre 2025Systèmes embarqués,ROS8min de lecture

OriginCar reliée à un ordinateur portable par câble Ethernet

Après avoir reçu une OriginCar équipée d’un RDK Horizon, le travail réel dépasse le simple fait de « lancer ROS 2 ». Il faut écrire l’image système sur une carte de stockage, flasher le programme de la carte principale, connecter l’ordinateur à l’appareil par le réseau, puis démarrer le châssis, la caméra et le client de bureau. Chaque étape dépend de la précédente.

Cet article transforme mes notes OriginCar en un parcours continu : préparer l’appareil, établir l’accès distant, démarrer les fonctions de base de ROS 2 et enfin transmettre les données du véhicule au client de bureau avec rosbridge. Les adresses par défaut, les versions logicielles et les commandes proviennent de notes historiques ; vérifiez-les avec l’image actuelle et la documentation RDK avant toute utilisation.

Cette configuration se divise en cinq couches :

Couche appareil : écrire l’image RDK sur une carte Micro SD et flasher le programme HEX sur la carte principale de l’OriginCar.
Couche réseau : placer l’ordinateur et le RDK sur un réseau capable de communiquer, par Ethernet ou Wi-Fi.
Couche système : se connecter au RDK par SSH et gérer les sources de paquets, les signatures GPG et le proxy.
Couche ROS 2 : démarrer le châssis, le contrôle au clavier, la caméra et rosbridge.
Couche bureau : exécuter le programme de bureau et se connecter aux topics et services ROS 2 via WebSocket.

Cette chaîne facilite la localisation des problèmes : vérifiez le flashage lorsque l’appareil ne démarre pas, le réseau lorsque l’ordinateur ne peut pas se connecter, les paquets et l’environnement lorsque les commandes ROS 2 échouent, puis rosbridge, l’adresse IP et le port lorsque le client de bureau ne reçoit aucune donnée.

Décompressez l’archive téléchargée pour obtenir un fichier .img, puis utilisez balenaEtcher :

Archive de l’image RDK OriginCar extraite

Cliquez sur Flash from file et sélectionnez le fichier .img extrait.
Cliquez sur Select target et choisissez la bonne carte Micro SD.
Cliquez sur Flash et attendez que l’outil confirme la fin de l’opération.

Confirmez le disque cible avant le flashage afin de ne pas sélectionner le disque local de l’ordinateur. Une fois l’écriture terminée, insérez la carte dans le RDK et allumez-le.

Sélection du fichier image dans balenaEtcher

Flashage terminé affiché par balenaEtcher

Utilisez l’outil FlyMcu2188 pour flasher le programme de la carte principale. Connectez l’ordinateur et la carte principale de l’OriginCar, puis sélectionnez le fichier HEX et le port série demandé par l’outil. Appuyez sur le bouton de réinitialisation de la carte pendant le flashage. Dans les notes historiques, les deux bandeaux lumineux latéraux s’allumaient après un flashage réussi.

Fichiers de flashage de la carte principale OriginCar

Paramètres de flashage FlyMcu2188

Connecteurs de la carte principale OriginCar

Les adresses par défaut historiques du RDK Horizon sont les suivantes :

Modèle	Adresse filaire par défaut relevée
RDK X3	192.168.1.10
RDK X5	192.168.127.10

Ces adresses proviennent de notes historiques sur l’image et la configuration réseau. Confirmez l’adresse actuelle sur l’appareil ou l’écran avant utilisation afin de distinguer une valeur par défaut de l’état réel.

Reliez l’ordinateur et l’OriginCar avec un câble Ethernet, puis configurez l’interface Ethernet de l’ordinateur sur le même sous-réseau que le RDK. Ouvrez MobaXterm, créez une session SSH et saisissez l’adresse IP, le port et l’utilisateur de connexion du RDK.

OriginCar reliée à un ordinateur portable par câble Ethernet

Référence officielle pour la connexion distante : RDK Remote Login.

Page de téléchargement de MobaXterm

Dans un terminal déjà connecté au RDK, utilisez les outils réseau fournis par l’image actuelle pour examiner le Wi-Fi :

sudo nmcli device wifi rescan
sudo nmcli device wifi list
sudo wifi_connect "SSID" "PASSWORD"
ifconfig

wifi_connect est une commande auxiliaire fournie par certains environnements d’image. Lorsque la commande est absente, utilisez la méthode de connexion standard de NetworkManager. Exécutez ifconfig ou ip addr pour obtenir la nouvelle adresse sans fil, puis utilisez-la pour créer la connexion SSH.

Les notes de l’image OriginCar incluent ROS 2 Foxy, TogetheROS et les pilotes bas niveau du véhicule. Après la connexion au RDK, démarrez le châssis :

ros2 launch origincar_base origincar_bringup.launch.py

Journal de démarrage du châssis OriginCar

Démarrez ensuite le contrôle au clavier dans un autre terminal :

ros2 run teleop_twist_keyboard teleop_twist_keyboard

L’OriginCar utilise une direction Ackermann ; le mouvement de direction dépend donc de la vitesse linéaire. Après le démarrage du nœud clavier, envoyez des commandes de vitesse avec les touches du terminal et observez la réponse du châssis.

Instructions des touches du nœud de contrôle clavier

La démonstration d’affichage caméra utilise ce fichier de lancement :

ros2 launch origincar_bringup usb_websocket_display.launch.py

Placez l’ordinateur et l’OriginCar sur le même réseau local, puis ouvrez cette adresse dans un navigateur :

http://<RDK_IP>:8000

Remplacez <RDK_IP> par l’adresse actuelle du RDK. Cette démonstration permet de vérifier la capture caméra et l’affichage réseau avant d’ajouter votre propre nœud de vision.

Les sources de paquets RDK doivent correspondre au modèle de l’appareil, au nom de code Ubuntu et au canal de publication. Connectez-vous au RDK et examinez l’environnement actuel :

cat /etc/version
. /etc/os-release
printf 'Ubuntu: %s\n' "$PRETTY_NAME"
dpkg --print-architecture
cat /etc/apt/sources.list.d/sunrise.list

La documentation actuelle de D-Robotics pour le RDK X5 s’appuie principalement sur des images Ubuntu 22.04 (jammy). Les anciennes images peuvent encore utiliser Ubuntu 20.04 (focal) ; la source doit suivre la version réelle de l’image.

Modifiez /etc/apt/sources.list.d/sunrise.list :

sudoedit /etc/apt/sources.list.d/sunrise.list

Conservez la ligne correspondant au modèle, à la version Ubuntu et au canal de publication actuels. Exemples pour le RDK X5 :

# Source stable RDK X5 Ubuntu 22.04
deb [signed-by=/usr/share/keyrings/sunrise.gpg] http://archive.d-robotics.cc/ubuntu-rdk-x5 jammy main

# Source beta RDK X5 Ubuntu 22.04
deb [signed-by=/usr/share/keyrings/sunrise.gpg] http://archive.d-robotics.cc/ubuntu-rdk-x5-beta jammy main

# Exemple historique pour une image Ubuntu 20.04
deb [signed-by=/usr/share/keyrings/sunrise.gpg] http://archive.d-robotics.cc/ubuntu-rdk-x5 focal main

Les sources stable et beta sont des canaux de publication distincts ; gardez la ligne correspondant à l’objectif actuel. L’exemple focal sert au dépannage des anciennes images. Pour une nouvelle image X5, vérifiez d’abord la configuration jammy officielle.

Enregistrez la clé au même emplacement que celui indiqué par signed-by dans la source :

sudo install -d -m 0755 /usr/share/keyrings
sudo curl -fsSL http://archive.d-robotics.cc/keys/sunrise.gpg \
  -o /usr/share/keyrings/sunrise.gpg
sudo chmod 0644 /usr/share/keyrings/sunrise.gpg
gpg --show-keys --fingerprint /usr/share/keyrings/sunrise.gpg

Les notes d’origine mentionnent NO_PUBKEY 599F576057BDF67C ainsi qu’une ancienne procédure utilisant apt-key pour récupérer une clé depuis un serveur de clés. La configuration actuelle utilise un trousseau indépendant et signed-by. Vérifiez l’empreinte et l’URL de téléchargement avec la documentation D-Robotics actuelle.

Après la mise à jour de la source et de la clé, actualisez l’index des paquets :

sudo apt update
apt-cache policy

Lorsqu’une erreur de signature persiste, vérifiez dans sunrise.list le domaine, le répertoire du modèle, le nom de code Ubuntu, le canal beta ou stable et le chemin du trousseau.

Le client de bureau communique avec ROS 2 grâce à rosbridge. Dans la configuration historique, la source et la clé ROS devaient être vérifiées avant l’installation de rosbridge :

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/ros-archive-keyring.gpg] http://packages.ros.org/ros2/ubuntu $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/ros2.list > /dev/null

sudo curl -sSL https://raw.githubusercontent.com/ros/rosdistro/master/ros.key \
  -o /usr/share/keyrings/ros-archive-keyring.gpg

Confirmez la version Ubuntu actuelle, la distribution ROS et la configuration officielle du dépôt avant d’exécuter ces commandes. Installez et démarrez rosbridge :

sudo apt install ros-$ROS_DISTRO-rosbridge-suite
ros2 launch rosbridge_server rosbridge_websocket_launch.xml

Journal de démarrage du service WebSocket rosbridge

Le client de bureau a besoin de l’adresse IP du RDK et du port WebSocket de rosbridge. Une fois la connexion établie, Foxglove ou le programme de bureau du projet peut lire les topics du véhicule et envoyer des commandes au châssis.

L’environnement de bureau historique demande des dépendances Python telles que keyboard, roslibpy, opencv-python et pyyaml :

Liste des fichiers du projet client de bureau

Répertoires et fichiers de lancement du client de bureau

pip install -r requirements.txt

Sous Windows, exécutez le code source ou le fichier bridge_client.exe empaqueté. Pour le code source :

python bridge_client.py <RDK_IP> <PORT>

Avant l’exécution, confirmez que map.png se trouve à côté de bridge_client.py. Pour la version binaire, placez map.png à côté de bridge_client.exe et définissez les paramètres de connexion dans config.yaml du même répertoire.

Sous Ubuntu, utilisez le script Shell fourni par le projet :

./bridge_client.sh

coScene ouvre l’interface de source de données

Pour empaqueter vous-même le client, utilisez la configuration PyInstaller du projet :

pyinstaller src/bridge_client.spec

Une fois la connexion établie, démarrez le châssis et rosbridge sur le RDK avant d’ouvrir la connexion dans le client de bureau. Cela sépare la vérification du pilote de châssis de la vérification de la connexion du client.

Lorsqu’une erreur telle que NO_PUBKEY apparaît, examinez l’adresse du dépôt, le nom de code de la distribution, le fichier de clé et son empreinte. Les notes d’origine utilisaient apt-key ; la méthode actuelle par trousseau doit suivre la version Ubuntu et la documentation officielle.

Examinez /etc/apt/sources.list.d/sunrise.list et confirmez que le modèle RDK, la version Ubuntu et le chemin de la source correspondent. Exemple historique :

deb [signed-by=/usr/share/keyrings/sunrise.gpg] http://archive.d-robotics.cc/ubuntu-rdk/ focal main

Cette ligne concerne uniquement l’environnement de source de paquets correspondant. Confirmez la version du système et les informations officielles de la source avant de la modifier.

Vérifiez dans cet ordre :

Le câble Ethernet, le Wi-Fi et l’interface réseau sont connectés.
L’ordinateur et le RDK se trouvent sur le même sous-réseau.
L’adresse IP actuelle du RDK n’a pas changé.
Les ports SSH, WebSocket ou de la page caméra sont corrects.
Le proxy du réseau local exclut les adresses locales avec NO_PROXY.

La configuration complète de détection automatique, de bascule manuelle et de transmission via sudo se trouve dans Configuration du proxy d’un environnement Ubuntu/RDK. Le petit exemple avec valeurs fictives ci-dessous permet de vérifier rapidement les variables de proxy local :

export HOST_IP="<PROXY_HOST>"
export PROXY_PORT="<HTTP_PORT>"
export SOCKS_PORT="<SOCKS5_PORT>"
export HTTP_PROXY="http://${HOST_IP}:${PROXY_PORT}"
export HTTPS_PROXY="http://${HOST_IP}:${PROXY_PORT}"
export ALL_PROXY="socks5://${HOST_IP}:${SOCKS_PORT}"
export NO_PROXY="localhost,127.0.0.1,::1,10.*,192.168.*,172.16.0.0/12"

Le parcours d’initiation ROS 2 de l’OriginCar forme une chaîne de vérification claire : confirmer le démarrage du système, vérifier que le réseau permet la connexion, vérifier le fonctionnement du châssis et de la caméra, puis confirmer que rosbridge échange des données avec le client de bureau. Chaque étape possède des entrées, des commandes et des observations explicites, ce qui facilite le dépannage lors de l’ajout ultérieur de la navigation, de la vision ou de nœuds de contrôle pour les compétitions.