둥's 이것저것

1. Setup

$ roscore
$ rosrun turtlesim turtlesim_node
$ rosrun turtlesim turtle_teleop_key

2. ROS Topics

위의 setup과정에서 실행한 turtlesim_node와 turtle_teleop_key 노드들은 ROS Topic을 통해 서로 통신하게 된다.

tuetle_teleop_key는 키보드의 입력을 publishing하게 되고 tuetlesim_node 노드는 같은 Topic을 subscribe하여 키의 입력을 전달받데 된다. 구조는 rqt_graph를 이용하여 쉽게 시각화시킬 수 있다.

2.1 Using rqt_graph

rqt_graph는 ROS 시스템의 구성을 그래프로 보여주는 도구로 rqt package의 한 부분이다.

아래 명령어를 통해 작업을 진행한다.

그럼 아래 명령어를 통해 Setup과정에서 진행한 ROS시스템의 구성을 살펴보자.

위의 그래프를 통해 /turtle1/command_velocity 라는 이름의 Topic에 대해 /teleop_turtle 노드와 tutlesim 노드가 메시지(데이터)를 통신하는 관계임을 확인할 수 있다.

2.2 Introducing rostopic

rostopic 툴은 ROS Topics에 대한 정보를 얻기 위한 도구이다.

2.3 Using rostopic echo

rostopic echo는 토픽에 대해 publish된 내용들을 표시해준다.

위와 같은 구조로 사용하게 되고 이를 예제 적용하여 보면

위의 명령어를 입력한 후 teleop_key 터미널창에 방향키 입력을 통해 거북이를 움직여보면 값이 변화하는 것을 확인할 수 있다.

이제 rqt_graph를 확인하여 보면 아래와 같이 붉은색으로 rostopic echo 노드가 생성되어 turtle1/command_velocity 토픽을

subscribe 하는것을 확인할 수 있다.

즉, turtle1/cmd_vel topic에 대해 teleop_turtle노드는 입력받는 키에 대한 정보를 publish하고 이를 나타내는 turtlesim 노드와 회전각 및 이동량을 전달받는 rostopic echo 노드가 topic을 subscribe하는 것을 확인할 수 있다.

2.4 Using rostopic list

rostopic list는 현재 topic에 대해 subscribe 및 publish 되는 노드들의 정보를 나타낸다.

rostopic list에 대한 argument들은 다음 명령어를 통해 확인할 수 있다.

3. ROS Messages

Topic들에 대한 통신(Communication)은 노드들 사이에 ROS 메시지를 전송함으로서 진행된다.

publisher(turtle_teleop_key)와 subscriber(turtlesim_node)가 통신하기 위해서는 각각 동일한 타입의 메시지를 송수신 하여야 한다.

즉, topic의 타입은 publish되는 메시지의 타입에 따라 정의되게 되고 이러한 토픽에 전송되는 메시지는 rostopic 타입을 통해 결정된다.

3.1 Using rostopic type

rostopic type는 publish되는 메시지 타입들을 보여준다.

우리의 예를 들면

위의 명령어를 통해 turtle1/cmd_vel 이라는 Topic의 메시지 타입을 확인하면 아래와 같은 결과를 확인할 수 있다.

그리고 메시지의 자세한 정보를 위해 rosmsg를 아래와 같이 사용하면 결과를 확인할 수 있다.

즉, geometry_msgs/Twist 라는 데이터 형은 직선방향, 각도에 대한 데이터형이고 이는 float64형임을 확인할 수 있다.

4. rostopic continued

4.1 Using rostopic pub

rostopic pub은 현재 토픽에서의 데이터를 publish한다.

위의 명령은 turtlesim 노드에게 직선속도 2.0과 각속도 1.8을 갖고 움직여라 라는 의미를 담고있다.

그럼 위와 같은 결과를 볼 수 있다.

굉장히 복잡한 명령어이므로 자세히 살펴보자.

우선 가장 앞에 등장하는 rostopic pub은 해당 topic에게 메시지를 전송하겠다는 것을 의미한다.

*  -1(dash-one) 은 한번의 메시지만 publish한 후 종료하라는 의미를 담고있다.

*  turtle1/cmd_vel 은 publish할 토픽의 이름을 나타낸다.

*  geometry_msgs/Twist 는 topic을 publish할 때, 메시지의 타입을 나타낸다.

*  --(double dash)는 해당 argument에 값을 넣어주지 않기 위한 과정이다.

*  앞에서와 같이 geometry/Twist 메시지는 각각 3개의 floating 요소들로 구성된다.

그리고 거북이를 계속 움직이기 위해선 아래 명령어와 같이 rostopic pub -r  명령어를 사용하자.

이 과정을 rqt를 이용해서 확인하여보면 아래와 같다.

보면 subscribe 노드는 rostopic echo 노드와 turtlesim 노드, publish는 teleop_turtle노드와 추가적으로

새로운 노드가 생성된 것을 확인할 수 있다.

즉 teleop_turtle로 키 입력을 받는 것 외에 계속적으로 움직임을 가질 수 있도록 새로운 노드가 생성되어 publish하는 것을

확인할 수 있다.

4.2 Using rostopic hz

rostopic hz는 어떤 데이터들이 publish 되는지 확인할 수 있다.

보면 average rate가 60과 가까운 것을 확인할 수 있고 이는 turtlesim 노드가 pose에 대한 데이터는 60Hz로 Publish 한다는

것을 의미한다.

5. Using rqt_plot

rqt_plot은 topics에 대해 publish되는 데이터의 연속적인 값들을 보여준다.

위의 명령어를 통해 rqt_plot을 진행하고 상단의 Topic에 그래프로 나타내고자 하는 토픽을 지정하고 옆의 + 버튼을 누르자.

근데 우분투 18.04버전을 진행함에 있어 다음과 같은 에러가 발생한다.

창의 크기를 조절하게 되면 다음과 같은 결과를 출력하며 강제 종료되게 된다.

이는 matplotlib 내부에 존재하는 문제로 아직 해결책을 찾지는 못하였지만 대체 방안으로 창을 최대화하면 보이는 것을 확인할 수 있다.

아래 링크는 해당 문제가 발생한 것에 대한 참고 링크이다.

github.com/ros-visualization/rqt_plot/issues/35

1. What makes up a catkin Package?

우선 내용을 다루기 전에 ROS에서 자주 등장하는 catkin이 무엇인지 알아보자.

Catkin은 ROS의 빌드 시스템으로 볼 수 있고 패키지들을 효율적으로 빌드하여 다른 상황에서 쉽게 사용될 수 있도록 한다.

ROS는 CMake를 ROS에 맞도록 특화면 catkin 빌드 시스템을 만들었다.

그럼 CMake는 무엇인가?

CMake는 플랫폼과 독립적으로 Build Process를 기술한 파일로 특정 IDE나 특정 빌드 도구에 한정되어 하나의 형식으로

한정되는(예를들어 Visual Studio의 sln/vcproj를 다른 플랫폼에서 바로 빌드할 수 없음) 문제점들을 CMake를 통해

해결할 수 있다.

ROS의 패키지들이 catkin package로 다뤄지기 위해선 몇가지 조건이 필요하다.

* 패키지는 반드시 catkin을 따르는 .xml파일이 필요하다.

   패키지.xml 파일은 패키지에 대한 메타 정보를 제공한다.

   (메타정보 : 데이터를 효율적으로 이용하기 위해 설명해놓은 정보)

* 패키지는 반드시 catkin을 사용하는 CMakeLists.txt 파일을 포함하고 있어야 한다.

* 각각의 패키지는 각각의 폴더를 갖고 있어야 한다.

   이는 다수의 패키지들이 같은 경로를 공유할 수 없다는 것을 의미한다.

2. Packages in a catkin Workspace

catkin 패키지들은 catkin workspace를 통해 사용하는 것이 좋지만 catkin 패키지만을 독립적으로 빌드할 수 있다.

workspace는 아래와 같은 형태를 갖는다.

튜토리얼을 시작하기 전에 새로운 empty catkin workspace를 만들자.

(참고: wiki.ros.org/catkin/Tutorials/create_a_workspace)

3. Creating a catkin Package

새로운 catkin package를 만들기 위한 catkin_create_pkg 스크립트 사용법을 다루고 이를 통해 할 수 있는 작업을 다룬다.

우선 위의 과정에서 생성한 empty catkin workspace에서의 경로에서 source 경로로 이동한다.

'beginner_tutorials'라는 새로운 패키지를 생성하기 위해 std_msgs, roscpp, rospy에 의존적인

catkin_create_pkg 스크립트를 사용한다.

위의 과정을 통해 package.xml, CMakeLists.txt 등이 담긴 beginner_tutorials 폴더를 생성하게 되고

catkin_create_pkg 패키지에 부여한 정보들을 통해 설정되게 된다.

우리는 [depend1], [depend2], [depend3]에 의존적인 package_name 패키지를 생성한 것이다.

4. Building a catkin workspace and sourcing the setup file

이제 catkin workspace의 패키지를 빌드해보자.

이를 진행하면 devel 디렉터리 안에 /opt/ros/melodic 안에 있는 내용들과 유사한 구조의 파일들이 생성되게 된다.

workspace를 ROS 환경에 추가하기 위해 아래 내용을 진행한다.

5. Package Dependencies

5.1 First-order dependencies

앞에서 catkin_create_pkg 패키지를 사용할때 몇가지 의존성을 설정하였다(roscpp, rospy, std_msgs).

이들은 rospack tool을 통해 확인할 수 있다.

위의 내용을 통해 rospack은 catkin_create_pkg를 실행할 때 사용되는 arguments들을 나타내는 것을 확인할 수 있다.

이러한 의존성(dependencies)는 package.xml 파일에 저장되게 된다.

5.2 Indirect Dependencies

대부분의 경우 하나의 dependency는 각각의 dependencies를 갖고 있는데 예를들어 rospy 패키지는 다음과 같은

dependencies를 갖는다.

그리고 패키지들은 다수의 직접적이지 않은(Indirect) dependencies를 갖는데 rospack을 통해 이들을 확인할 수 있다.

6. Customizing Your Package

catkin_create_pkg를 통해 실행되는 파일들을 살피며 각각의 Customizing을 통해 패키지를 설정한다.

6.1 Customizing the package.xml

새로운 패키지 안의 package.xml 파일이 실행된다.  package.xml을 살펴보자.

6.1.1 description tag

.xml 파일의 line5에 위치한 description 부분을 수정한다. 문장은 짧게 구성되어야 하고 짧게 구성하기 힘든 경우

분할하여 작성하여야 한다.

6.1.2 maintainer tags

이는 다른 사람들이 패키지와 관련하여 어떻게 컨텍할 수 있을지 표기하는 부분이다. 적어도 하나의 maintainer tag가 요구되고

maintainer의 이름은 tag의 중앙부에 위치시킨다.

혹은 이메일을 남기기도 한다.

6.1.3 license tags

open source 라이센스나 소프트웨어 라이센스 등을 표시한다.

6.1.4 dependencies tags

dependencies는 build_depend, buildtool_depend, exec_depend, test_depend 로 나뉘어진다.

자세한 내용은 wiki.ros.org/catkin/package.xml#Build.2C_Run.2C_and_Test_Dependencies 를 참고하자.

위의 과정에서 std_msgs, roscpp, rospy를 catkin_create_pkg 패키지의 arguments로 설정하였으므로

다음과 같이 표시된다.

catkin 에서의 buildtool_depend를 디폴트로 하여 지정한 dependencies들이 표시된다.

우리의 경우 지정한 dependencies들이 빌드과정과 실행과정에서 모두 사용 가능하기를 원하므로 exec_depend 태그를

추가해준다.

6.1.5 Final package.xml

최종적인 xml 파일의 형태를 확인한다.

6.2 Customizing the CMakeLists.txt

위의 과정을 통해 package.xml 파일은 당신의 package에 맞게 최적화되었다.

CMakeLists.txt 파일은 ROS 코드를 빌드하는 과정을 통해 변경되게 될 것이다.

이렇게 ROS Package를 생성하는 과정을 진행하였다.