La base mobile LeKiwi

La base LeKiwi est une plateforme open-source à 3 roues omnidirectionnelles réparties à 120°. Cette configuration en fait une base holonome : elle peut se déplacer dans n’importe quelle direction sans avoir à se réorienter au préalable.

Dans cette partie, vous découvrez le robot, vous le lancez en simulation pour inspecter son graphe ROS 2 et comprendre qui parle à qui (et comment il transforme une consigne de vitesse en rotation de roues), puis vous le téléopérez pour valider sa cinématique.

Vue d’ensemble du robot

Les trois roues sont identiques, montées sur des moteurs indépendants et réparties à 120° autour du châssis :

• left_wheel à 60° (avant-gauche) ;
• right_wheel à 300° (avant-droit) ;
• back_wheel à 180° (arrière).

Chaque roue est omnidirectionnelle (roue + galets latéraux) : elle n’entraîne le sol que dans son axe principal et glisse librement latéralement. C’est la combinaison des trois qui produit un mouvement holonome — la base translate dans n’importe quelle direction sans avoir à se réorienter.

Au centre, un LiDAR 360° (laser_link) balaie l’environnement — c’est lui qui rendra la cartographie possible. La pose est estimée à partir de l’odométrie des roues (affinée, en simulation, par une IMU ; sur un robot réel sans IMU, les roues seules suffisent et le SLAM corrige la dérive).

Visualiser le modèle (URDF)

Avant la sim physique, on peut afficher le modèle seul (URDF + RViz) :

ros2 launch lekiwi_description display.launch.py

Cela démarre robot_state_publisher + RViz avec une config qui charge le modèle ; vous pouvez agiter les roues avec le joint_state_publisher_gui.

Exercice express — le graphe minimal

Avec uniquement display.launch.py lancé (pas de sim physique), explorez le graphe et répondez avant le corrigé :

1. Combien de nœuds tournent, et lesquels ?
2. Qui publie /robot_description ? Qui publie /joint_states ?
3. /scan et /cmd_vel sont-ils présents ? (On en reparle juste après.)

Afficher les réponses

Les commandes pour répondre (introspection de base) :

ros2 node list      # quels nœuds tournent ?
ros2 topic list     # quels topics existent ?
ros2 topic echo /joint_states --once

1. Trois : /robot_state_publisher, /joint_state_publisher_gui et /rviz2.
2. /robot_state_publisher publie /robot_description (et /tf, /tf_static) ; /joint_state_publisher_gui publie /joint_states (les positions que vous bougez avec les curseurs).
3. Ni l’un ni l’autre n’est là. Gardez ce constat en tête : on lance la simulation à l’étape suivante et on observe ce qui change.

Inspecter le robot avec Foxglove

RViz reste notre outil d’interaction 3D, mais pour inspecter ce qui circule sur le graphe — voir le robot et lire les valeurs brutes des topics — Foxglove est plus confortable (interface web, panneaux Raw Messages et Plot, pas de GPU requis).

Gardez display.launch.py lancé et démarrez le pont dans un autre terminal :

ros2 launch foxglove_bridge foxglove_bridge_launch.xml   # ws://localhost:8765

Dans l’application Foxglove (cf. Installation), connectez-vous à ws://localhost:8765, puis ajoutez deux panneaux :

• un panneau 3D : pour voir le maillage du robot (et pas seulement les repères), ajoutez une couche URDF via Custom layers → + → URDF. Réglez Source = Parameter et Parameter = robot_description (la source Topic refuse /robot_description, qui est un std_msgs/String). La base suit ensuite la tf en direct ;
• un panneau Raw Messages abonné à /joint_states : vous y lisez en direct la valeur de chaque articulation.

Robot mal orienté ou meshes invisibles : trois réglages

La visu 3D de Foxglove a trois pièges classiques avec un robot ROS — tous côté affichage, la TF reste correcte :

1. Meshes tournés de 90° (roues/lidar « couchés ») : les .stl n’ont pas d’axe vertical, et Foxglove est par défaut en Y-up. Mettez Scene → Mesh up-axis = Z-up (la convention ROS). C’est le réglage qui fait que RViz est correct mais pas Foxglove.
2. Vue de travers : réglez Display frame = base_footprint (repère au sol) et Follow mode = Position only pour que la caméra ne bascule pas quand le robot tourne.
3. Meshes absents (robot réduit à des axes) : foxglove_bridge n’a pas pu résoudre package://lekiwi_description/.... Relancez le pont depuis un terminal sourcé (source ~/ros2_bootcamp_ws/install/setup.bash).

Exercice — Plotter un joint qui bouge dans Foxglove

Le topic /joint_states (sensor_msgs/JointState) publie les positions des trois roues : left_wheel_joint, back_wheel_joint, right_wheel_joint. Faisons tourner les roues et traçons leur valeur en direct.

1. Faites bouger les roues : soit en téléop (teleop_azerty, le robot roule donc les roues tournent), soit avec le joint_state_publisher_gui si vous êtes en display.launch.py.

2. Dans un panneau Raw Messages sur /joint_states, relevez la valeur (en radians) du champ position de la roue qui tourne.

3. Ajoutez un panneau Plot et saisissez le message path par index :

   /joint_states.position[0]

   /joint_states (sensor_msgs/JointState) utilise des tableaux parallèles : name[] et position[] sont indexés dans le même ordre. Le filtre par nom (position[:]{name==...}) ne marche pas ici, car position est un tableau de flottants nus, sans champ name par élément. On adresse donc par index — repérez l’ordre dans un panneau Raw Messages :

   Index	Roue
   position[0]	left_wheel_joint
   position[1]	back_wheel_joint
   position[2]	right_wheel_joint

   La courbe monte en marche avant (roue continuous : la position s’incrémente sans borne) et descend en marche arrière. Ajoutez position[1] et position[2] pour comparer les trois roues.

Lancer la simulation

ros2 launch lekiwi_bringup sim_base.launch.py

Ce launch ouvre Gazebo Ionic sur le monde bootcamp.sdf (une enceinte 8 × 8 m avec plusieurs obstacles et trois zones repères colorées), spawn la base LeKiwi et démarre toute la chaîne logicielle : robot_state_publisher, le pont ros_gz (/clock, /scan, /imu/data), les contrôleurs ros2_control, twist_mux et l’EKF.

Une seule sim à la fois

La sim utilise ros2_control : ne lancez pas deux sim_base en parallèle (collision du controller_manager). Entre deux essais, tuez les gz sim / robot_state_publisher orphelins.

Découvrir le graphe du robot

Le robot tourne : avant de le piloter, inspectez son graphe ROS 2 pour comprendre qui parle à qui. Dans un nouveau terminal, lancez vous-même la visualisation :

ros2 run rqt_graph rqt_graph

Activez l’affichage des topics (cochez Nodes/Topics) : vous devez retrouver les nœuds ros_gz, twist_mux, controller_manager et ekf_filter_node reliés par leurs topics.

Vérifiez votre compréhension

En explorant le graphe, répondez avant de regarder le corrigé :

1. Voyez-vous maintenant /scan et /cmd_vel (absents avec display.launch.py) ? Pourquoi sont-ils apparus ?
2. Quel nœud publie /scan ? De quel type est ce topic ?
3. Qui consomme /cmd_vel pour faire bouger les roues ?
4. D’où vient /odometry/filtered, et quelle transformation tf ce nœud publie-t-il ?
5. Voyez-vous déjà l’action /navigate_to_pose ? Pourquoi ?

Afficher les réponses

1. Oui, les deux sont là maintenant. La différence avec display.launch.py : la simulation ajoute un LiDAR simulé (→ /scan) et des contrôleurs (→ /cmd_vel). Avec display, on ne faisait qu’afficher le modèle ; ici Gazebo le fait vivre (capteurs + actionneurs).
2. Le pont ros_gz (parameter_bridge) republie le LiDAR simulé sur /scan, de type sensor_msgs/msg/LaserScan.
3. Le contrôleur omni_wheel_drive_controller (via le controller_manager). En amont, c’est twist_mux qui alimente /cmd_vel.
4. Du nœud ekf_filter_node (robot_localization), qui fusionne /odom (roues) + /imu/data et publie la tf odom → base_footprint.
5. Non : /navigate_to_pose est exposée par Nav2, qui n’est pas encore lancé. Ici on n’a que la base + la perception, pas la pile de navigation.

L’architecture : de /cmd_vel aux roues

En reliant les réponses ci-dessus, vous reconstituez la chaîne des commandes de vitesse — du clavier (ou de Nav2) jusqu’aux roues :

Du clavier (ou de Nav2) jusqu’aux roues, en passant par twist_mux et omni_wheel_drive_controller.

twist_mux arbitre les sources (la téléop est prioritaire sur Nav2) et tous ces topics sont en geometry_msgs/TwistStamped — c’est pourquoi le téléop AZERTY publie directement des TwistStamped sur /cmd_vel_teleop.

Le dernier maillon, omni_wheel_drive_controller, est un plugin ros2_control (chargé par le controller_manager). C’est lui — et pas un nœud maison — qui transforme une consigne (vx, vy, ω) en vitesse pour chacune des trois roues. Pour une roue i située à l’angle θᵢ du centre :

$$v_i = -\sin(\theta_i)\, v_x + \cos(\theta_i)\, v_y + L\, \omega$$

avec L = rayon entre le centre du robot et chaque roue (≈ 0,13 m sur le LeKiwi). C’est cette cinématique inverse qui, en combinant les trois roues, produit le mouvement holonome. En retour, le contrôleur publie l’odométrie /odom (intégration des vitesses de roues), que l’EKF fusionnera avec l’IMU.

L’architecture ros2_control de la base : la même pile en simulation et sur le robot réel — seul le hardware interface change.

Pourquoi passer par ros2_control ?

Le calcul cinématique vit dans un contrôleur standard, configurable et réutilisable, pas dans du code spécifique au robot. Le controller_manager le charge, l’active et lui fournit les interfaces matérielles (hardware_interface) — le même contrôleur fonctionne en simulation comme sur le robot réel.

Téléopération clavier

Pour valider la cinématique, pilotez la base au clavier avec le téléop AZERTY fourni par le bootcamp : il publie directement des TwistStamped sur /cmd_vel_teleop — aucun remap ni option à ajouter.

Terminal 1 — sim

ros2 launch lekiwi_bringup sim_base.launch.py

Terminal 2 — téléop

ros2 run lekiwi_bringup teleop_azerty

Touches (clavier AZERTY) :

• z / s : avancer / reculer
• q / d : translation latérale gauche / droite (la magie d’une base holonome)
• a / e : rotation gauche / droite
• espace : arrêt
• + / - : vitesse linéaire ; * / : : vitesse angulaire

Si la base se déplace latéralement sans changer de cap, la cinématique est correcte. ✅

Clavier QWERTY ?

Vous pouvez aussi utiliser le téléop standard, en le remappant vers /cmd_vel_teleop et en activant les messages stampés :

ros2 run teleop_twist_keyboard teleop_twist_keyboard \
  --ros-args -r /cmd_vel:=/cmd_vel_teleop -p stamped:=true

Observer pendant la téléop

Pendant que vous pilotez, regardez les données circuler :

ros2 topic echo /cmd_vel_teleop      # vos consignes (TwistStamped)
ros2 topic echo /odometry/filtered   # la pose estimée par l'EKF
ros2 run tf2_tools view_frames       # arbre des frames -> frames.pdf

Dans frames.pdf, vous obtenez la chaîne odom → base_footprint → base_link → roues / laser_link. Il n’y a pas encore de frame map : sans SLAM, le robot sait comment il a bougé (odométrie) mais pas où il est dans une carte. C’est précisément ce qu’on ajoute à la page suivante.

Prochaine étape

Navigation autonome avec Nav2 — cartographier puis naviguer.