clion ros srv include CMakeList the ins and outs

Disclaimer: This article is a blogger summer hui's original article, shall not be reproduced without the bloggers allowed. https://blog.csdn.net/shanpenghui/article/details/89955879

Ros in the development of server time, reference ros tutorial http://wiki.ros.org/ROS/Tutorials/WritingServiceClient%28c%2B%2B%29
client source code file, there are:

#include "beginner_tutorials/AddTwoInts.h"

Just start to feel very strange, in fact, include the header file does not exist, why can be placed here, and you can compile it?

In fact, the official tutorial and explains some clues:

beginner_tutorials/AddTwoInts.h is the header file generated from the srv file that we created earlier.

That this header file is generated by srv file! And what srv files are? In this example, the file content AddTwoInts.srv but four lines:

int64 a
int64 b
---
int64 sum

In fact, this document defines the service from the start, the service description file is divided into two parts: the request and the response is "-" symbol spaced.
The real reason is .msg / .srv / .action files before using require a special pre-compilation step. The following explanation is that these concepts macros, as well as steps on how to make it work properly.
The key is to create the macro programming language-specific files, may be used for the programming language of messages, services and operations. Construction system will use all available generators (e.g. gencpp, genpy, genlisp etc.) to generate the binding.
In CMakeList, these three macros are provided three message handler:

add_message_files

add_service_files

add_action_files

Then, these macros must be called after calling generates the macro:

 generate_messages（）

Note that this need to distinguish between order! !
These macros must precede catkin_package () macro to generate work.

 find_package（catkin REQUIRED COMPONENTS ...）
 add_message_files（...）
 add_service_files（...）
 add_action_files（...）
 generate_messages（...）
 catkin_package（...）
 ...

The catkin_package () macro must have CATKIN_DEPENDS dependency on message_runtime.

catkin_package（
 ...
 CATKIN_DEPENDS message_runtime ...
 ...）

And must be find_package () for coating messagesegeneration, may be used alone, it may be used as a component catkin:

find_package（catkin REQUIRED COMPONENTS message_generation）

And this time, also need to modify package.xml, because of the need to add a dependency message_runtime runtime. If this dependence is passed over from other packages can not change, but most of the time be safe or change it.
The final step in three cases:

If only one target (even transfer) depends on the need to build other targets msg / srv / action, it is necessary to add an explicit dependency on the target catkin_EXPORTED_TARGETS, constructed so that they are in the correct order. Unless you own part of the package does not contain any ros, otherwise you must add the explicit dependencies. Of course, if you do not add it, the program will not be automatically added.

add_dependencies(some_target ${catkin_EXPORTED_TARGETS})

If you have a build package msg and / or srv, and use them executable file, you must create an explicit dependence on the automatically generated message destination so that they can be compiled in the correct order.

add_dependencies(some_target ${${PROJECT_NAME}_EXPORTED_TARGETS})

If your package to meet the above two conditions, you must add two dependencies.

add_dependencies(some_target ${${PROJECT_NAME}_EXPORTED_TARGETS} ${catkin_EXPORTED_TARGETS})

In summary, a complete CMakeList as follows:

  # 获取pkg编译依赖的信息
  find_package(catkin REQUIRED
    COMPONENTS message_generation std_msgs sensor_msgs)

  # 声明需要编译的msg文件
  add_message_files(FILES
    MyMessage1.msg
    MyMessage2.msg
  )

  # 声明需要编译的srv文件
  add_service_files(FILES
    MyService.srv
  )

  # 实际上生成特定语言的消息和服务文件
  generate_messages(DEPENDENCIES std_msgs sensor_msgs)

  # 声明catkin包运行时依赖
  catkin_package(
   CATKIN_DEPENDS message_runtime std_msgs sensor_msgs
  )

  # 定义可执行文件的源代码
  add_executable(message_program src/main.cpp)
  add_dependencies(message_program ${${PROJECT_NAME}_EXPORTED_TARGETS} ${catkin_EXPORTED_TARGETS})
  # 或者
  add_dependencies(message_program {PROJECT_NAME}_generate_messages_cpp)

  # 定义不使用这个package中任何消息/服务的其他任意可执行文件
  add_executable(does_not_use_local_messages_program src/main.cpp)
  add_dependencies(does_not_use_local_messages_program ${catkin_EXPORTED_TARGETS})
  # 或者
  add_dependencies(message_program {PROJECT_NAME}_generate_messages_cpp)

Wherein, to be noted that the main difference between that and the catkin_EXPORTED_TARGETS $ {PROJECT_NAME} _EXPORTED_TARGETS deriving target construct contains all the former dependency (ie: message service, operation of generating a target dynamic_reconfig etc.), which contains only the target current packet .

Finally, in the actual development process, if they were srv include the header file does not exist in the case can not be compiled, you find setup.bash devel files in the current working space under the folder:

source <you workspace path>/devel/setup.bash

Then run inside the terminal may clion friends

. <clion installed path>/clion.sh

Of course, because it is dynamically generated, if copying the code will certainly prompt beginner_tutorial wrong, because this name is generated by CMakeList inside the project name, so in the development process, the need to replace the path of the header file #include "(project_name / include_name) ", and the related class names should be replaced project_name.

If there are other issues to explore little friends are welcome.

clion ros srv include CMakeList the ins and outs

Guess you like