Optimiser l'intégration continue en robotique avec les simulations Gazebo : étude de cas
Dans le domaine de la robotique, où la précision et l'efficacité sont cruciales, les outils et les technologies jouent un rôle important dans l'amélioration des projets. Cependant, l'un des défis les plus importants réside dans la garantie de la qualité et de la fiabilité des logiciels, en particulier dans le contexte de projets complexes tels que les robots capables de décider de manière autonome dans des environnements inconnus et en évolution dynamique.
De plus, la complexité des systèmes modernes logiciel robotique ne saurait être sous-estimée. Elle englobe une multitude de domaines, notamment le SLAM (localisation et cartographie simultanées), la navigation, la perception, l'intégration avec des systèmes externes, les états du robot, et bien d'autres. Ces domaines impliquent souvent plusieurs équipes travaillant en collaboration, chacune livrant en continu du code qui doit fonctionner correctement dans des environnements divers. Assurer la vérification continue de notre logiciel constitue donc, en soi, un défi redoutable.
Explorons les avantages de cette intégration et la manière dont elle peut être mise en œuvre avec succès en pratique, en particulier lorsqu'il s'agit de robots conçus pour la navigation autonome dans des environnements divers et dynamiques, où des tests approfondis de leur comportement sont primordiaux et où les méthodes de test traditionnelles sont souvent insuffisantes.
Quelques mots sur Gazebo et les simulations Gazebo
Gazebo est un puissant outil de simulation qui joue un rôle fondamental dans le domaine de la robotique, particulièrement en conjonction avec le Robot Operating System (ROS). Il constitue un environnement de simulation dynamique et polyvalent pour les robots, permettant aux ingénieurs et aux chercheurs de créer et de tester leurs systèmes robotiques virtuellement, sans avoir besoin de multiples déplacements au laboratoire. Essentiellement, Gazebo est une solution qui fait gagner du temps, permettant aux développeurs d'itérer et d'affiner leurs créations dans un monde simulé sans risque.
L'une des caractéristiques notables de Gazebo est son intégration transparente avec ROS, le framework largement adopté pour le développement de logiciels robotiques. Cette intégration permet aux roboticistes d'exploiter toute la puissance de ROS au sein de l'environnement simulé. Gazebo fait office de pont entre les mondes physique et virtuel, ce qui en fait un outil essentiel pour le prototypage, les tests et le perfectionnement des systèmes robotiques. Il permet aux ingénieurs d'expérimenter différentes conceptions de robots, d'affiner les algorithmes de contrôle et de valider les systèmes de perception, tout en bénéficiant de l'écosystème étendu de packages et de bibliothèques ROS.
Sans aucun doute, l'un des aspects les plus précieux à mentionner est la nature open source deGazebo. Cette base favorise une communauté florissante de passionnés, fournit des exemples d'utilisation pratiques et promeut la collaboration. Cet environnement collaboratif améliore non seulement l'accessibilité de ces outils, mais accélère également le rythme du développement robotique. De plus, l'intégration transparente avec ROS fait de Gazebo un choix idéal pour les applications robotiques, permettant aux utilisateurs de créer des robots virtuels, de simuler des capteurs et de s'engager dans un large éventail d'activités robotiques axées sur la précision et l'efficacité.
Avons-nous vraiment besoin de l'IC pour le développement logiciel en robotique ?
C'était juste une question rhétorique pour vous réveiller 😉 Mais, plus sérieusement, l'intégration continue en robotique joue effectivement le même rôle fondamental que dans tout autre projet logiciel. Elle fournit un retour rapide à l'équipe de développement, garantit la qualité logicielle par le biais de tests automatisés, du versionnage et facilite les déploiements automatisés. Comme pour tout projet, l'un de nos principaux objectifs est d'éviter les régressions. En substance, nous cherchons à empêcher notre robot de perdre de manière inattendue l'une de ses capacités et à rendre le processus de livraison stable et reproductible.
Cependant, la différence réside dans la complexité de la robotique. Dans ce domaine, nous sommes confrontés à une multitude de scénarios potentiels qui peuvent survenir lorsqu'un robot interagit avec un environnement dynamique et en constante évolution. Contrairement aux logiciels traditionnels, les robots doivent s'adapter aux conditions du monde réel, ce qui ajoute une couche de difficulté supplémentaire. L'intégration continue (CI) en robotique ne se limite pas à maintenir la qualité du code ; il s'agit de garantir que le comportement d'un robot reste cohérent et fiable face à une multitude de situations possibles. Ainsi, bien que la CI serve un objectif similaire, son importance en robotique devient encore plus prononcée en raison des subtilités du domaine.
Explorer la synergie : intégrer les simulations Gazebo dans la CI robotique
La synergie entre Gazebo et l'IC est cruciale, car elle combine les avantages des tests réalistes dans les environnements virtuels de Gazebo avec l'efficacité des tests automatisés via l'IC. Cette intégration permet aux roboticistes de valider leurs systèmes de manière complète et efficace, en garantissant que les robots peuvent fonctionner de manière fiable face aux nombreux défis présentés par le monde réel.
La création de tests avec l'environnement de simulation Gazebo nous aide à éviter les erreurs imprévues qui peuvent survenir à n'importe quelle étape d'un projet. C'est important car ces projets impliquent souvent de multiples niveaux de complexité. Prenons, par exemple, les composants de navigation ou de cartographie tels que SLAM (Simultaneous Localisation and Mapping). Bien qu'ils puissent fonctionner comme des nœuds séparés, ils travaillent souvent ensemble pour atteindre un objectif commun.
Avec l'IC, nous acquérons la capacité d'exécuter plusieurs tests simultanément dans un environnement isolé (Conteneur Docker). Un exemple, qui montre l'avantage de cette approche, est l'amélioration des algorithmes utilisés en robotique. À chaque itération ou mise à jour d'un algorithme donné, nous nous attendons à une augmentation des performances. L'exécution simultanée d'un ensemble de tests nous permet d'évaluer si un nouvel algorithme surpasse son prédécesseur en termes d'efficacité. De plus, grâce à l'intégration de Gazebo, nous obtenons un aperçu de la performance de ces algorithmes non seulement dans des tests synthétiques, mais aussi dans le monde virtuel.
Intégrer Gazebo à un pipeline CI robotique : un guide technique détaillé
Ce que nous testons et ce que nous attendons
Dans ce cas d'usage, notre intégration de Gazebo avec CI est démontrée à travers l'exemple de notre robot autonome, AvatarEn bref, le robot Avatar passe par une phase initiale d'exploration de la pièce afin d'obtenir une carte de son environnement. Cette carte sert de base aux activités ultérieures, notamment la navigation et bien d'autres.
Le logiciel côté robot est conçu à l'aide de ROS2, avec l'implémentation des domaines pertinents via des nœuds, tels que SLAM, Navigation, Perception, Robot Status, Robot State et Robot-to-Cloud Integration, garantissant les fonctionnalités mentionnées précédemment. De plus, nous avons utilisé les technologies et structures présentées ci-dessous.
Un diagramme présenté illustre les étapes simples d'IC mises en œuvre pour cette partie du projet :
Dans cet article, nous examinerons de plus près l'étape des simulations Gazebo. Nous explorerons également l'un des scénarios de test exécutés dans notre simulateur. À travers cela, nous nous familiariserons avec un modèle pouvant être utilisé pour ajouter d'autres scénarios. Dans notre exemple, le scénario de test portera sur la phase d'exploration du robot.
Pour mieux comprendre le scénario, vous pouvez vous référer aux trois images fournies ci-dessous. La première image montre le début de l'exploration, où la carte n'est que partiellement découverte.
Dans la deuxième image, vous pouvez observer le processus d'exploration en cours, comme indiqué par les tuiles vertes surRViz, en marquant les zones qui ont été explorées jusqu'à présent.
La dernière image montre l'aboutissement de l'exploration, avec tous les champs dans RViz désormais rendus en vert, indiquant la découverte complète de la zone cartographiée. À présent, notre robot possède une connaissance précise des dimensions de la pièce et de l'emplacement des murs ou des obstacles – nous avons terminé l'exploration. La prochaine étape pour l'Avatar consiste à rechercher des démonstrations dans la pièce, puis à s'y rendre. L'intégration de l'IC et des simulations Gazebo nous aidera à optimiser et à corriger les bugs de l'algorithme d'exploration, en veillant à ce que notre robot puisse traverser différentes pièces sans rester piégé parmi les obstacles ou bloqué contre un mur.
Quelques mots sur les simulations Gazebo et la préparation à l'IC
Pour faire fonctionner Gazebo dans un environnement d'Intégration Continue (CI), il est essentiel de comprendre comment Gazebo fonctionne. Gazebo se compose de deux modules principaux : « gzclient » et « gzserver ». « gzclient » gère principalement l'aspect de visualisation de la simulation sur notre matériel. Comme vous pouvez l'imaginer, ce module ne sera pas nécessaire à des fins de CI.
Le composant essentiel de notre configuration CI est « gzserver », qui fonctionne en mode headless sans interface graphique. Ce module est responsable de l'exécution de l'ensemble de la simulation du monde, et il sera utilisé dans notre processus de test.
Frameworks que nous utiliserons
Le programme conçu pour lancer Gazebo, ainsi que tous les nœuds, est scripté en Python (launcher). Ce lanceur basé sur Python rationalise la gestion des processus pendant les tests. Le projet Avatar a été développé à l'aide du framework ROS2 dans sa version Galactic, ce qui nous a offert une flexibilité dans le choix d'un langage de programmation pour nos besoins.
Pour l'écriture des tests, j'ai choisi d'utiliser le C++ conjointement avec le framework de test de Google. Cependant, rien ne nous empêche d'utiliser des alternatives telles que Python ou d'adopter un autre framework de test pour cette tâche.
Tester l'implémentation
Pour tester notre workflow, nous devons lancer un launcher basé sur Python.
Ce lanceur est responsable du lancement des nœuds qui contrôlent divers aspects du robot, tels queNavigation2 pour le déplacement des robots et Slam Toolbox pour la cartographie des pièces.
De plus, il lance un monde virtuel dans Gazebo. Ci-dessous, vous trouverez le code de ce lanceur, accompagné de brèves descriptions de ses fonctions :
# Lanceur avec définition de monde virtuel gazebo
def launchers():
return [
IncludeLaunchDescription(
PythonLaunchDescriptionSource(
os.path.join(get_package_share_directory('virtual_world'), 'launch', 'avatar_launch.py')),
launch_arguments={x: LaunchConfiguration(x) for x in (
'x_pose', 'y_pose', 'world', 'use_rviz')}.items(),
condition=IfCondition(LaunchConfiguration('use_virtual_world')))
]
# Arguments du lanceur
def launch_args():
launcher_root = get_package_share_directory('avatar_robot')
return [
# Arguments par défaut
DeclareLaunchArgument(
'params_file',
default_value=os.path.join(
launcher_root, 'params', 'sim_diamond.yaml'), # Paramètres pour la simulation
description='Chemin complet du fichier de paramètres ROS2 à utiliser pour tous les nœuds lancés'),
DeclareLaunchArgument(
'use_virtual_world',
default_value='True',
description='Lancer le lanceur de monde virtuel'),
DeclareLaunchArgument(
'use_gzclient',
default_value='False', # Ne pas utiliser gzclient - Seul gzserver est requis
description='Lancer le client Gazebo'),
DeclareLaunchArgument(
'use_rviz',
default_value='True',
description='Lancer RViz'),
DeclareLaunchArgument('world', default_value='diamond_demos'), # Nom du monde
DeclareLaunchArgument('x_pose', default_value='2.10'), # Position de départ du robot (x)
DeclareLaunchArgument('y_pose', default_value='1.62'), # Position de départ du robot (y)
]
def generate_launch_description():
params_file = LaunchConfiguration('params_file')
custom_map_path = LaunchConfiguration('custom_map_path')
return LaunchDescription(
launch_args() + [
cmd_slam_bringup(params_file),
cmd_nav2_bringup(params_file, custom_map_path),
cmd_nav_node(params_file),
cmd_visualization_node(params_file),
cmd_calc_node(params_file),
cmd_exploration_node(params_file),
] + launchers()
)Pour exécuter ce lanceur dans notre test, nous allons créer un simple wrapper C++ pour le gérer :
class ProcessManager {
public:
// Termine le processus s'il est en cours d'exécution
~ProcessManager() {
if (m_pid.has_value()) {
killProcess();
}
}
// Vérifie si le processus est en cours d'exécution
bool isProcessRunning() const {
return m_pid.has_value() && kill(m_pid.value(), 0) == 0;
}
// Termine le processus et attend sa fin
bool killProcess(int sig = SIGINT) {
if (m_pid.has_value() == false) {
return true;
}
kill(m_pid.value(), sig);
waitpid(m_pid.value(), nullptr, 0);
const bool isStillRunning = isProcessRunning();
m_pid.reset();
return isStillRunning;
}
// Fork le programme et démarre un nouveau processus
template<typename ... Args>
pid_t runProcess(const char * program, Args ... args) {
static_assert(std::conjunction_v<std::is_same<const char *, Args>...>);
if (m_pid.has_value()) {
return m_pid.value();
}
const pid_t pid = fork();
if (pid == 0) {
execlp(program, program, args ..., nullptr);
}
m_pid = pid;
return pid;
}
private:
std::optional<pid_t> m_pid;
};Une fois que nous avons configuré les arguments nécessaires pour ce lanceur, nous pouvons l'initier dans le code :
// Sujet du statut d'exploration static constexpr auto avatarTilesTopic = "avatar_tiles"; // Délais d'attente static constexpr std::int64_t LOOP_TIMEOUT_IN_SEC = 5; // 5 sec // L'exploration doit prendre jusqu'à 3 minutes static constexpr std::int64_t EXPLORATION_TIMEOUT_IN_SEC = 3 * 60; // 3 min // Position initiale aléatoire du robot (doit être valide) const auto randomPosition = RobotValidPositions.getRandomPoint(); // Arguments du lanceur const std::string xStartRobArg = "x_pose:=" + std::to_string(randomPosition.x); const std::string yStartRobArg = "y_pose:=" + std::to_string(randomPosition.y); const std::string worldArg = "world:=" + worldName; const std::string rvizArg = "use_rviz:=False"; // Gestionnaire du lanceur test_utils::ProcessManager avatarLauncher; // Démarrer le nœud avatar avatarLauncher.runProcess( "ros2", "launch", "avatar_robot", "simulation_launch.py", rvizArg.c_str(), worldArg.c_str(), xStartRobArg.c_str(), yStartRobArg.c_str()); // Vérifier si le processus est en cours d'exécution ASSERT_TRUE(avatarLauncher.isProcessRunning()) << "Impossible de démarrer le lanceur avatar";
L'étape suivante consiste à mettre en place une vérification de l'état d'exploration. Le robot publie systématiquement des messages sur le sujet « avatar_tiles » pour signaler sa progression d'exploration. Pour ce faire, nous devrons écrire un simple nœud abonné chargé de surveiller l'état d'exploration :
// Défini sur true si tous les threads doivent être terminés
std::atomic_bool stopThreads = false;
// Initialisation de ros
rclcpp::init(0, nullptr);
// Vérifie si l'exploration est terminée
std::atomic_bool isExplorationFinished = false;
auto processTiles = [&](const tiles_avatar_msgs::msg::Tiles & tiles) {
// Vérifie si toutes les tuiles ont été traitées
if (std::all_of(
std::begin(tiles.tiles),
std::end(tiles.tiles),
[](decltype(tiles.tiles)::value_type tile) {
return static_cast<utils::TileState>(tile.state) == utils::TileState::eProcessed;
})) {
// Si toutes les tuiles ont été traitées, l'exploration est terminée
isExplorationFinished = true;
}
};
// Crée un nœud ROS et s'abonne au topic
auto temporaryNode = std::make_shared<rclcpp::Node>("test_scan_entire_room_node");
auto subscription = rclcpp::create_subscription<tiles_avatar_msgs::msg::Tiles>(
temporaryNode, avatarTilesTopic, 10, processTiles);
À ce stade, nous attendons simplement la fin de l'exploration et évaluons si les résultats des tests correspondent à nos attentes :
// Attendre la fin de l'exploration std::future<void> explorationWaitFuture = std::async( std::launch::async, [&]() { while (isExplorationFinished != true && stopThreads == false) { std::this_thread::sleep_for(std::chrono::seconds{LOOP_TIMEOUT_IN_SEC}); } }); // Arrêter le nœud ROS une fois l'exploration terminée std::future<void> rosShutdown = std::async( std::launch::async, [&]() -> void { explorationWaitFuture.wait_for(std::chrono::seconds{EXPLORATION_TIMEOUT_IN_SEC}); rclcpp::shutdown(); }); // Faire tourner le nœud jusqu'à ce que l'exploration fonctionne rclcpp::spin_until_future_complete( temporaryNode, explorationWaitFuture, std::chrono::seconds{EXPLORATION_TIMEOUT_IN_SEC}); // Vérifier si le délai d'attente a été dépassé const bool isTimeout = std::future_status::timeout == explorationWaitFuture.wait_for( std::chrono::seconds( 0)); EXPECT_FALSE(isTimeout) << "Après " << EXPLORATION_TIMEOUT_IN_SEC << " secondes, le robot n'a pas terminé l'exploration"; // Vérifier si l'exploration a réussi EXPECT_TRUE(isExplorationFinished) << "Le robot ne peut pas terminer l'exploration."; // Tuer le lanceur avatarLauncher.killProcess(); // Vérifier si le lanceur a été tué EXPECT_FALSE(avatarLauncher.isProcessRunning()) << "Impossible d'arrêter le lanceur avatar"; // Attendre que toutes les tâches asynchrones se terminent stopThreads = true; explorationWaitFuture.wait(); rosShutdown.wait();
Enfin, nous concluons en appelant les fonctions au sein du framework GoogleTest :
TEST(test_exploration, test_scan_rectangle_demos) { // Create robot starting position (valid) test_utils::ValidPosition RobotValidPositions; RobotValidPositions.addBox(Point{1.12, 4.54}, Point{1.64, 0.59}); RobotValidPositions.addBox(Point{2.32, 4.13}, Point{3.8, 1.11}); RobotValidPositions.addBox(Point{3.92, 4.72}, Point{4.61, 3.65}); RobotValidPositions.addBox(Point{3.51, 1.88}, Point{4.52, 0.43}); // Start test for "rectangle_demos" world run_scan_test("rectangle_demos", RobotValidPositions); }
Configuration du pipeline CI
Après avoir préparé les tests, nous avons l'intention de téléverser nos modifications dans le dépôt afin de vérifier leur bon fonctionnement ; il est donc temps de configurer notre CI sur GitLab. La première étape consiste à sélectionner une image – le choix optimal étant une image préinstallée avec des dépendances telles que ROS ou Gazebo pour éliminer les installations répétées. Dans notre cas, nous disposons d'une image préalablement préparée et stockée sur le serveur :
default: image: synergy/ros_galactic:3.2
Comme pour le diagramme de flux CI, il comprendra 5 étapes :
stages: - static_code_analysis - build - test - simulation_test - deploy
Chaque étape a une tâche légèrement différente, mais concentrons-nous sur celle qui nous intéresse le plus – simulation_test :
simulation_test: stage: simulation_test script: - . install/setup.sh - colcon test --packages-up-to exploration_sim - colcon test-result --all artifacts: when: always expire_in: '1 day' paths: - build/**/test_results/**/*.xml - install/ reports: junit: build/**/test_results/**/*.xml
À cette étape, un seul paquet – exploration – est testé à l'aide de simulations Gazebo. De plus, les journaux générés pendant le test seront stockés dans GitLab pendant une journée.
L'utilisation de GitLab, ROS et de l'IC simplifie considérablement le processus de lancement et de collecte des tests.
Résultat du test
Après l'implémentation, il est nécessaire de vérifier la fonctionnalité de notre test et d'évaluer si le robot l'a réussi. Pour ce faire, nous téléchargeons le code dans notre dépôt Git et attendons les résultats des tests. Comme l'illustrent les journaux fournis ci-dessous, notre robot a réussi les tests avec succès, l'exploration ayant été achevée en 113 secondes.
Start 1: test_scan_entire_room
1: Commande de test : /usr/bin/python3 "-u" "/opt/ros/galactic/share/ament_cmake_test/cmake/run_test.py" "/builds/robotics/avatar/avatar_robot/build/test_scan_entire_room/test_results/test_scan_entire_room/test_scan_entire_room.gtest.xml" "--package-name" "test_scan_entire_room" "--output-file" "/builds/robotics/avatar/avatar_robot/build/test_scan_entire_room/ament_cmake_gtest/test_scan_entire_room.txt" "--command" "/builds/robotics/avatar/avatar_robot/build/test_scan_entire_room/test_scan_entire_room" "--gtest_output=xml:/builds/robotics/avatar/avatar_robot/build/test_scan_entire_room/test_results/test_scan_entire_room/test_scan_entire_room.gtest.xml"
1: Délai d'expiration du test calculé à : 2700
1: -- run_test.py : appel de la commande suivante dans '/builds/robotics/avatar/avatar_robot/build/test_scan_entire_room':
1: - /builds/robotics/avatar/avatar_robot/build/test_scan_entire_room/test_scan_entire_room --gtest_output=xml:/builds/robotics/avatar/avatar_robot/build/test_scan_entire_room/test_results/test_scan_entire_room/test_scan_entire_room.gtest.xml
1: Exécution de main() depuis /opt/ros/galactic/src/gtest_vendor/src/gtest_main.cc
1: [==========] Exécution de 1 test depuis 1 suite de tests.
1: [----------] Configuration globale de l'environnement de test.
1: [----------] 1 test depuis test_exploration
1: [ RUN ] test_exploration.test_scan_rectangle_demos
1: [INFO] [launch]: Tous les fichiers journaux peuvent être trouvés ci-dessous /root/.ros/log/2023-09-25-13-00-42-781057-runner-pyozp9em-project-81-concurrent-0jp5zf-718
1: [INFO] [launch]: La verbosité de journalisation par défaut est définie sur INFO
... ... ...
1: [INFO] [controller_server-6]: le processus s'est terminé proprement [pid 743]
1: [INFO] [bt_navigator-9]: le processus s'est terminé proprement [pid 749]
1: [INFO] [gzserver-19]: le processus s'est terminé proprement [pid 909]
1: [ OK ] test_exploration.test_scan_rectangle_demos (113240 ms)
1: [----------] 1 test depuis test_exploration (113240 ms au total)
1: [----------] Démontage global de l'environnement de test
1: [==========] 1 test depuis 1 suite de tests exécuté. (113240 ms au total)
1: [ PASSED ] 1 test.
1: -- run_test.py : code de retour 0
1: -- run_test.py : injection du préfixe de nom de classe dans le fichier de résultats gtest '/builds/robotics/avatar/avatar_robot/build/test_scan_entire_room/test_results/test_scan_entire_room/test_scan_entire_room.gtest.xml'
1: -- run_test.py : vérification du fichier de résultats '/builds/robotics/avatar/avatar_robot/build/test_scan_entire_room/test_results/test_scan_entire_room/test_scan_entire_room.gtest.xml'
1/5 Test #1: test_scan_entire_room ............ Réussi 113.29 sec
Résumé de la mise en œuvre
L'implémentation présentée ici démontre une méthode rapide et simple d'intégration des simulations Gazebo avec la CI. Grâce à cela, nous pouvons protéger notre projet contre les régressions.
Un aspect notable de cette implémentation est son adaptabilité. Elle peut être facilement modifiée pour s'adapter à différents scénarios, notamment l'ajout de nouveaux cas de test, de différents modèles de robots ou de mondes virtuels alternatifs. Pour introduire de la variété dans les tests, nous pouvons utiliser des variables aléatoires, telles qu'un changement de la position initiale du robot, garantissant ainsi que chaque test sera légèrement différent du précédent.
En outre, envisagez d'utiliser unrosbag pour enregistrer des topics. Cette capacité d'enregistrement peut s'avérer précieuse en cas d'erreur, car elle permet une lecture et une analyse faciles — une ressource particulièrement utile lorsqu'il s'agit de problèmes sporadiques ou peu fréquents qui doivent être reproduits et étudiés.
GitLab vous permet de stocker des artefacts pour un pipeline, permettant, comme démontré dans « CI Integration », non seulement de stocker des rapports gtest mais aussi d'enregistrer des enregistrements rosbag.
Résumé
Avantages de la connexion de Gazebo à l'IC
L'intégration de l'IC avec Gazebo nous dote d'une capacité puissante pour développer des tests qui servent de garde-fous contre les régressions de projet. Cette synergie nous permet d'évaluer simultanément de nombreux scénarios sans avoir besoin de matériel physique. Nous pouvons même exécuter des tests nocturnes qui explorent des cas extrêmes, tels que la modification des positions initiales du robot, des simulations Gazebo offrant différents environnements virtuels, ou même l'utilisation de différents modèles de robots dans divers environnements.
L'un des avantages les plus importants de cette approche est sa rentabilité. Dans un environnement d'équipe collaborative, nous n'avons plus besoin d'un robot physique pour chaque membre de l'équipe, ce qui se traduit par des économies substantielles et une optimisation des ressources pour le projet.
Le plan d'intégration de l'IC avec Gazebo reste analogue à celui de divers autres projets. Le meilleur exemple est celui des drones, que Gazebo prend également en charge. Les capacités de Gazebo définissent principalement nos limites, et celles-ci sont d'une ampleur impressionnante.
Vous recherchez des spécialistes en robotique ?
Découvrez comment nous pouvons accompagner votre prochain produit – consultez notre Services de robotique, et n'hésitez pas à nous contacter en cas de questions.
FAQ
L'intégration continue en robotique est la pratique consistant à construire, tester et valider automatiquement les logiciels robotiques à chaque introduction de modifications. Les pipelines CI permettent aux équipes de détecter les problèmes d'intégration précocement et de vérifier le comportement des robots à l'aide de tests automatisés et de simulations.
Les simulations permettent aux équipes de robotique de tester le comportement sans nécessiter de matériel physique. Des outils tels que Gazebo permettent d'exécuter des scénarios reproductibles dans un pipeline CI, ce qui permet la validation automatisée des algorithmes de navigation, d'exploration ou de perception.
Gazebo fournit un environnement de simulation réaliste pour les robots et les capteurs. Lorsqu'il est intégré à un pipeline CI, Gazebo peut exécuter automatiquement des scénarios de test et rapporter les résultats, aidant ainsi les équipes à valider les modifications logicielles avant le déploiement.
Les pipelines CI améliorent la fiabilité et la vitesse de développement. Les builds, tests et simulations automatisés permettent de détecter les problèmes tôt, de réduire l'effort de test manuel et de garantir que le logiciel robotique se comporte correctement à travers les différentes mises à jour.
arrow_circle_rightContactez-nous
Transformez votre industrie avec des solutions robotiques. Contactez notre expert pour en savoir plus
Piotr Wierzba
Cofondateur et directeur de la Business Unit Chemicals
arrow_circle_right Autres articles
