L'espace de travail ROS est un répertoire utilisé pour stocker les packages de travail ROS. Ces packages de travail contiennent divers fichiers de programmes ROS, y compris le code source, les fichiers de configuration et les fichiers de message. Ainsi, l'essence de l'espace de travail est un dossier, qui est utilisé pour stocker les packages qui seront introduits ensuite et les fichiers nécessaires pour créer ces packages. De nombreux espaces de travail ROS peuvent être créés, et ils sont tous indépendants les uns des autres, exécutant des programmes spécifiques dans leurs espaces de travail respectifs, ce qui évite que des programmes non liés ne soient assemblés, et suit également le concept de conception de couplage lâche Les avantages sont évidents . les fonctions ensemble facilitent le débogage.
1. Espace de travail ROS
Nouvel espace de travail (répertoire)
mkdir -p ~/catkin_ws/src
cd ~/catkin_ws/srcSpécifiez -p pour créer plusieurs répertoires inexistants, c'est-à-dire tous les répertoires de ce chemin, s'ils n'existent pas, ils seront créés. De plus, pour créer un nouvel espace de travail, on le crée généralement sous le répertoire racine de l'utilisateur courant ~/
Initialiser l'espace de travail
catkin_init_workspace
#Creating symlink "/home/yahboom/catkin_ws/src/CMakeLists.txt" pointing to "/opt/ros/melodic/share/catkin/cmake/toplevel.cmake"L'essentiel ici est de créer un lien symbolique pointant vers toplevel.cmake .Le résultat est de rendre l'ensemble du système visible.
Une fois l'espace de travail créé et initialisé, créez d'autres fichiers d'espace de travail :
cd ~/catkin_ws
catkin_makeLa commande catkin_make compilera tous les nœuds et gardera toutes les dépendances à jour. Vérifions quels répertoires sont ajoutés au répertoire src : ls
construire devel src
Il existe un répertoire build et devel supplémentaire . Le répertoire build est l'endroit où catkin stocke les bibliothèques et les programmes exécutables lors de l'utilisation de C++. Si nous utilisons Python, nous pouvons ignorer le contenu du build , et le devel se concentre principalement sur le fichier setup.bash . , l'exécution de ces fichiers oblige le système à utiliser l'espace de travail et le code qu'il contient.
Pour configurer avec la commande suivante, ajoutez (>>) setup.bash à .bashrc :
echo "source ~/catkin_ws/devel/setup.bash" >> ~/.bashrc
source ~/.bashrcL'espace de travail est si agréablement nouvellement construit. Ensuite, afin de vous familiariser avec un point complet, utilisez C++ pour faire une compilation et voyez quelles opérations connexes doivent être effectuées.
2. Forfait ROS
Le nom de « paquet », le logiciel dans Ubuntu existe également sous la forme d'un paquet, mais le paquet dans ROS est différent du paquet dans Ubuntu. Puisqu'il s'agit spécifiquement du système d'exploitation du robot, le « paquet » mentionné plus loin fait référence au package ROS, s'il s'agit d'un package Ubuntu, il indiquera spécifiquement qu'il s'agit d'un package Ubuntu.
La commande pour créer le package :
catkin_create_pkg tony_code rospyCette commande catkin_create_pkg , également apparue dans l'article précédent, l'introduction de la compilation du système d'exploitation du robot ROS Catkin et l'utilisation de commandes communes , est une commande très courante.
Cela crée avec succès un nouveau package nommé tony_code , qui contient les fichiers CMakeLists.txt et package.xml , et un dossier src pour stocker le code source réel.Ce package dépend du package rospy existant.Si votre package Cela dépend également d'autres packages, qui peut être listé sur la ligne de commande.
Une structure de répertoires de cet espace de travail est à peu près la suivante :
|--- catkin_ws /
|------ build /
|------ devel /
|------ src /
|---- CMakeLists.txt
|---- tony_code /
|- --- CMakeLists.txt package.xml src
|---- Autre /
|---- CMakeLists.txt package.xml src
Il y aura plusieurs CMakeLists.txt ici qui doivent être distingués. En plus d'un sous le répertoire src du répertoire racine de l'espace de travail, chaque package a également un CMakeLists.txt
2.1、CMakeLists.txt
Comme mentionné ci-dessus, en plus d'un CMakeLists.txt dans l'espace de travail , chaque package en a également un. Lorsque nous compilons le package, nous modifions le CMakeLists.txt sous le package correspondant.
C'est très simple pour les lecteurs familiarisés avec Make .Ce fichier définit comment compiler le code source dans le lot de travaux.
Vérifions le contenu du fichier CMakeLists.txt dans le nouveau package tony_code : cat CMakeLists.txt
projet cmake_minimum_required (VERSION 3.0.2)
(tony_code)## Compiler en C++11, pris en charge dans ROS Kinetic et plus récent
# add_compile_options(-std=c++11)## Trouver des macros et des bibliothèques catkin
## si la liste COMPONENTS comme find_package(catkin REQUIRED COMPONENTS xyz)
## est utilisée, trouver également d'autres packages catkin
find_package(catkin REQUIRED COMPONENTS
rospy
)## Les dépendances système sont trouvées avec les conventions de CMake
# find_package(Boost REQUIRED COMPONENTS system)
## Décommentez ceci si le paquet a un setup.py. Cette macro garantit que
## les modules et les scripts globaux qui y sont déclarés sont installés
## Voir http://ros.org/doc/api/catkin/html/user_guide/setup_dot_py.html
# catkin_python_setup()###############################################
## Déclarer les messages, services et actions ROS ##
######################################## ######### Pour déclarer et créer des messages, des services ou des actions à partir de ce
## package, suivez ces étapes :
## * Soit MSG_DEP_SET l'ensemble des packages dont vous utilisez les types de message dans
## vos messages/services/actions (par exemple, std_msgs, actionlib_msgs, ...).
## * Dans le fichier package.xml :
## * ajoutez une balise build_depend pour "message_generation"
## * ajoutez une balise build_depend et une balise exec_depend pour chaque package dans MSG_DEP_SET
## * Si MSG_DEP_SET n'est pas vide, la dépendance suivante a été extrait
## mais peut néanmoins être déclaré avec certitude :
## * ajoutez une balise exec_depend pour "message_runtime"
## * Dans ce fichier (CMakeLists.txt) :
## * ajoutez "message_generation" et chaque package dans MSG_DEP_SET à
## find_package(catkin REQUIRED COMPONENTS ...)
## * ajoutez "message_runtime" et chaque package dans MSG_DEP_SET à
## catkin_package(CATKIN_DEPENDS ...)
## * décommentez les sections add_*_files ci-dessous si nécessaire
## et répertoriez chaque fichier .msg/.srv/.action à traiter
## * décommentez l'entrée generate_messages ci-dessous
## * ajoutez chaque paquet dans MSG_DEP_SET à generate_messages(DEPENDENCIES ...)## Générer des messages dans le dossier 'msg'
# add_message_files(
# FILES
# Message1.msg
# Message2.msg
# )## Générer des services dans le dossier 'srv'
# add_service_files(
# FILES
# Service1.srv
# Service2.srv
# )## Générer des actions dans le dossier 'action'
# add_action_files(
# FILES
# Action1.action
# Action2.action
# )## Générer des messages et des services ajoutés avec toutes les dépendances répertoriées ici
# generate_messages(
# DEPENDANCES
# std_msgs # Ou d'autres packages contenant des msgs
# )###############################################
## Déclarer les paramètres de reconfiguration dynamique ROS ##
########################################## ####### Pour déclarer et construire des paramètres de reconfiguration dynamique dans ce
## package, suivez ces étapes :
## * Dans le fichier package.xml :
## * ajoutez une balise build_depend et une balise exec_depend pour "dynamic_reconfigure"
## * Dans ce fichier ( CMakeLists.txt):
## * ajoutez "dynamic_reconfigure" à
## find_package(catkin REQUIRED COMPONENTS ...)
## * décommentez la section "generate_dynamic_reconfigure_options" ci-dessous
## et listez chaque fichier .cfg à traiter## Générer les paramètres de reconfiguration dynamique dans le dossier 'cfg'
# generate_dynamic_reconfigure_options(
# cfg/DynReconf1.cfg
# cfg/DynReconf2.cfg
# )##################################
## configuration spécifique catkin ##
######## ###########################
## La macro catkin_package génère des fichiers de configuration cmake pour votre paquet
## Déclarez les éléments à transmettre aux projets dépendants
# # INCLUDE_DIRS : décommentez ceci si votre package contient des fichiers d'en-tête
## LIBRARIES : les bibliothèques que vous créez dans ce projet dont les projets dépendants ont également besoin
## CATKIN_DEPENDS : les projets dépendants de catkin_packages ont également besoin de
## DEPENDS : les dépendances système de ce projet dont les projets dépendants ont également besoin de
catkin_package (
# INCLUDE_DIRS include
# LIBRARIES tony_code
# CATKIN_DEPENDS rospy
# DEPENDS system_lib
)###########
## Construire ##
############# Spécifiez des emplacements supplémentaires pour les fichiers d'en-tête
## Les emplacements de vos packages doivent être répertoriés avant les autres emplacements
include_directories(
# include
${catkin_INCLUDE_DIRS}
)## Déclarer une bibliothèque C++
# add_library(${PROJECT_NAME}
# src/${PROJECT_NAME}/tony_code.cpp
# )## Ajoutez les dépendances cibles cmake de la bibliothèque
## à titre d'exemple, le code peut devoir être généré avant les bibliothèques
## soit à partir de la génération de message ou de la reconfiguration dynamique
# add_dependencies(${PROJECT_NAME} ${${PROJECT_NAME}_EXPORTED_TARGETS} ${catkin_EXPORTED_TARGETS })## Déclarez un exécutable C++
## Avec catkin_make, tous les packages sont construits dans un seul contexte CMake
## Le préfixe recommandé garantit que les noms de cible des packages ne se heurtent pas
# add_executable(${PROJECT_NAME}_node src/tony_code_node.cpp)## Renommer l'exécutable C++ sans préfixe
## Le préfixe recommandé ci-dessus provoque des noms de cible longs, ce qui suit renomme la
cible ## vers la version plus courte pour faciliter l'utilisation par l'utilisateur
## par exemple "rosrun somes_pkg node" au lieu de "rosrun somes_pkg somes_pkg_node"
# set_target_properties(${PROJECT_NAME}_node PROPERTIES OUTPUT_NAME nœud PREFIX "")## Ajoutez les dépendances cibles cmake de l'exécutable
## comme pour la bibliothèque ci-dessus
# add_dependencies(${PROJECT_NAME}_node ${${PROJECT_NAME}_EXPORTED_TARGETS} ${catkin_EXPORTED_TARGETS})## Spécifiez les bibliothèques pour lier une bibliothèque ou une cible exécutable à
# target_link_libraries(${PROJECT_NAME}_node
# ${catkin_LIBRARIES}
# )#############
## Installer ##
############## toutes les cibles d'installation doivent utiliser les variables catkin DESTINATION
# Voir http://ros.org/doc/api/catkin/html/adv_user_guide/variables.html## Marquez les scripts exécutables (Python, etc.) pour l'installation
## contrairement à setup.py, vous pouvez choisir la destination
# catkin_install_python(PROGRAMS
# scripts/my_python_script
# DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION}
# )## Marquer les exécutables pour l'installation
## Voir http://docs.ros.org/melodic/api/catkin/html/howto/format1/building_executables.html
# install(TARGETS ${PROJECT_NAME}_node
# RUNTIME DESTINATION ${CATKIN_PACKAGE_BIN_DESTINATION}
# )## Marquer les bibliothèques pour l'installation
## Voir http://docs.ros.org/melodic/api/catkin/html/howto/format1/building_libraries.html
# install(TARGETS ${PROJECT_NAME}
# ARCHIVE DESTINATION ${CATKIN_PACKAGE_LIB_DESTINATION}
# DESTINATION DE LA BIBLIOTHÈQUE ${CATKIN_PACKAGE_LIB_DESTINATION}
# DESTINATION D'EXÉCUTION ${CATKIN_GLOBAL_BIN_DESTINATION}
# )## Marquez les fichiers d'en-tête cpp pour l'installation
# install(DIRECTORY include/${PROJECT_NAME}/
# DESTINATION ${CATKIN_PACKAGE_INCLUDE_DESTINATION}
# FILES_MATCHING PATTERN "*.h"
# PATTERN ".svn" EXCLUDE
# )## Marquez les autres fichiers pour l'installation (par exemple, les fichiers de lancement et de sac, etc.)
# install(FILES
# # monfichier1
# # monfichier2
# DESTINATION ${CATKIN_PACKAGE_SHARE_DESTINATION}
# )#############
## Test ##
############### Ajouter une cible de test cpp basée sur gtest et des bibliothèques de liens
# catkin_add_gtest(${PROJECT_NAME}-test test/test_tony_code.cpp)
# if(TARGET ${PROJECT_NAME}-test)
# target_link_libraries(${PROJECT_NAME}-test ${PROJECT_NAME} )
# endif()## Ajouter des dossiers à exécuter par python nosetests
# catkin_add_nosetests(test)
D'après le contenu du texte CMakeLists.txt , nous comprenons également qu'il est utilisé pour décrire les informations de configuration pour la construction d'un ou plusieurs projets logiciels. En modifiant la configuration, CMake peut générer automatiquement des scripts de construction basés sur les informations de configuration du projet pour compiler , testez et installez le logiciel.
Selon vos propres besoins, supprimez les commentaires si vous avez besoin de les utiliser. Par exemple, dans la configuration, vous devez ajouter le répertoire du fichier d'en-tête, puis ouvrez include_directories
Lorsque vous utilisez opencv , vous devez inclure le fichier d'en-tête /usr/local/include/opencv/cv.h . Nous incluons son répertoire : include_directories(/usr/local/include) Ajoutez lors de l'appel de la fonction : #include "opencv/cv.h"
D'autres configurations seront expliquées plus tard lorsqu'elles seront nécessaires.
2.2, package.xml
Ce fichier package.xml contient les méta-informations du package de travail, telles que le nom du package, le numéro de version, les dépendances, etc.
Vérifions le contenu de ce fichier : cat package.xml
<?xml version="1.0"?>
<package format="2">
<name>tony_code</name>
<version>0.0.0</version>
<description>The tony_code package</description>
<!-- One maintainer tag required, multiple allowed, one person per tag -->
<!-- Example: -->
<!-- <maintainer email="[email protected]">Jane Doe</maintainer> -->
<maintainer email="[email protected]">yahboom</maintainer>
<!-- One license tag required, multiple allowed, one license per tag -->
<!-- Commonly used license strings: -->
<!-- BSD, MIT, Boost Software License, GPLv2, GPLv3, LGPLv2.1, LGPLv3 -->
<license>TODO</license>
<!-- Url tags are optional, but multiple are allowed, one per tag -->
<!-- Optional attribute type can be: website, bugtracker, or repository -->
<!-- Example: -->
<!-- <url type="website">http://wiki.ros.org/tony_code</url> -->
<!-- Author tags are optional, multiple are allowed, one per tag -->
<!-- Authors do not have to be maintainers, but could be -->
<!-- Example: -->
<!-- <author email="[email protected]">Jane Doe</author> -->
<!-- The *depend tags are used to specify dependencies -->
<!-- Dependencies can be catkin packages or system dependencies -->
<!-- Examples: -->
<!-- Use depend as a shortcut for packages that are both build and exec dependencies -->
<!-- <depend>roscpp</depend> -->
<!-- Note that this is equivalent to the following: -->
<!-- <build_depend>roscpp</build_depend> -->
<!-- <exec_depend>roscpp</exec_depend> -->
<!-- Use build_depend for packages you need at compile time: -->
<!-- <build_depend>message_generation</build_depend> -->
<!-- Use build_export_depend for packages you need in order to build against this package: -->
<!-- <build_export_depend>message_generation</build_export_depend> -->
<!-- Use buildtool_depend for build tool packages: -->
<!-- <buildtool_depend>catkin</buildtool_depend> -->
<!-- Use exec_depend for packages you need at runtime: -->
<!-- <exec_depend>message_runtime</exec_depend> -->
<!-- Use test_depend for packages you need only for testing: -->
<!-- <test_depend>gtest</test_depend> -->
<!-- Use doc_depend for packages you need only for building documentation: -->
<!-- <doc_depend>doxygen</doc_depend> -->
<buildtool_depend>catkin</buildtool_depend>
<build_depend>rospy</build_depend>
<build_export_depend>rospy</build_export_depend>
<exec_depend>rospy</exec_depend>
<!-- The export tag contains other, unspecified, tags -->
<export>
<!-- Other tools can request additional information be placed here -->
</export>
</package>Ce fichier contient un ensemble de métadonnées sur le nouveau package. Introduisons les nœuds respectivement :
name : Le nom du package, ce nœud ne peut pas être modifié ! !
version : le numéro de version du paquet
description : une brève description de la fonctionnalité du paquet
mainteneur : le mainteneur du paquet et la personne qui corrige le bogue, plusieurs personnes
licence : la licence
url : l'URL du paquet
auteur : l'auteur de le package
buildtool_depend : l'outil de construction, dans ROS, il s'agit essentiellement de catkin
build_depend : dependency
export : informations requises par des outils autres que catkin
3. Compiler C++
Avec les connaissances ci-dessus, nous utilisons C++ pour écrire le nœud le plus simple, puis le compiler et nous familiariser avec l'ensemble du processus et les erreurs rencontrées.
3.1, Créer un nouveau package minimal
Selon l'introduction ci-dessus, créez un nouveau package, ici le nom est minimal
cd ~/catkin_ws/src
catkin_create_pkg minimal rospy3.2. Code C++
Après avoir créé le package, nous créons un fichier C++ dans le répertoire src sous le package minimal
cd minimal/src
gedit minimal.cppLe contenu de minimal.cpp est le suivant
#include <ros/ros.h>
int main(int argc,char **argv)
{
ros::init(argc,argv,"minimal");
ros::NodeHandle n;
ros::spin();
return 0;
}Il s'agit du nœud ROS le plus simple écrit en C++, incluant un fichier d'en-tête ROS.
ros::init(argc,argv,"minimal"); Initialisez le nœud et nommez-le minimal, ce qui équivaut à l'espace de noms
ros::NodeHandle n; Créez un descripteur de nœud pour créer des sujets, des services et des actions. En Python, il n'est pas nécessaire de créer explicitement un descripteur de nœud de cette manière, car l'interface Python de ROS peut implicitement implémenter
ros::spin() ; il a attendu l'ordonnancement de ROS. Si c'est simple à comprendre, comme le traitement de la fonction de rappel lors de l'abonnement, il sera toujours Le sens de l'abonnement cyclique. Bien sûr, vous rencontrerez une fonction comme ros::spinOnce(); dans la dernière étape , ce qui signifie la même chose, mais cela est généralement placé dans une boucle.
3.3. Modifier CMakeLists.txt
Ensuite le fichier de configuration est modifié, il faut encore faire attention ici, le fichier CMakeLists.txt sous le package minimal est utilisé.
cd ~/catkin_ws/src/minimal
gedit CMakeLists.txtModifiez les trois endroits suivants et supprimez les commentaires pour le rendre effectif :
find_package(catkin REQUIRED rospy)
add_executable(minimal src/minimal.cpp)
target_link_libraries(minimal ${catkin_LIBRARIES})3.4, compiler
Après la configuration, nous commençons à compiler :
cd ~/catkin_ws
catkin_makeLors de la compilation ici, il convient de noter que vous devez retourner au répertoire racine de l'espace de travail à compiler.
Bien que trois emplacements aient été modifiés, la compilation signale toujours l'erreur suivante. Le fichier d'en-tête ros/ros.h est introuvable . Il s'agit d'une erreur très courante :
Analyse des dépendances de la cible minimal
[ 50 %] Construction de l'objet CXX minimal/CMakeFiles/minimal.dir/src/minimal.cpp.o
/home/yahboom/catkin_ws/src/minimal/src/minimal.cpp:1:10 : erreur fatale : ros/ros.h : aucun fichier ou répertoire de ce type
#include <ros/ros.h>
^~~~~~~~~~~
compilation terminée.
minimal/CMakeFiles/minimal.dir/build.make:62 : la recette pour la cible 'minimal/CMakeFiles/minimal.dir/src/minimal.cpp.o' a échoué
make[2] : *** [minimal/CMakeFiles/minimal. dir/src/minimal.cpp.o] Erreur 1
CMakeFiles/Makefile2:431 : la recette pour la cible 'minimal/CMakeFiles/minimal.dir/all' a échoué
make[1] : *** [minimal/CMakeFiles/minimal.dir/ all] Erreur 2
Makefile:140 : la recette pour la cible 'all' a échoué
make :
Échec de l'appel de "make -j2 -l2"
3.5, gestion des erreurs de compilation
Pour l'erreur de compilation ci-dessus, elle est également introduite ci-dessus. Il y a des fichiers d'en-tête ici, vous devez donc ouvrir include_directories
include_directories(inclure ${catkin_INCLUDE_DIRS})
Ensuite, compilez à nouveau, toujours une erreur, démarrez le gestionnaire de nœuds roscore , il peut être démarré normalement, donc la configuration de la variable d'environnement ne pose aucun problème. La raison en est que C++ est utilisé ici , donc ce package de dépendance roscpp est nécessaire, et la modification est la suivante :
find_package(catkin COMPOSANTS REQUIS rospy roscpp)
Puis recompilez sans problème. Comme indiqué sur l'image :
De cette manière, le programme exécutable minimal compilé est placé dans ~/catkin_ws/devel/lib/minimal/minimal .