ROS Interface
ROS 2의 노드는 정해진 형태의 데이터를 주고받으며 서로 협력합니다. 이때 사용하는 데이터 형식과 통신 규칙을 인터페이스라고 합니다. ROS 2의 대표적인 인터페이스에는 토픽, 서비스, 액션이 있습니다.
토픽(Topic)
토픽(Topic)에 대한 설명은 ROS 2 Jazzy 공식 Docs의 자료를 사용합니다. 보다 자세한 내용은 아래 링크를 참고해 주세요.
ROS 2는 데이터를 메시지(Message)라는 이름으로 전송합니다. 자주 사용되거나 기본적인 형태의 메시지는 미리 만들어져 있어서, 가져와서 바로 사용할 수 있습니다. 만약, 원하는 형태의 메시지가 없다면 .msg 형태의 파일을 생성하여 custom 메시지를 사용할 수 있습니다.
토픽(Topic)은 데이터를 전송하는 Publisher와 데이터를 수신하는 Subscriber간의 단방향 메시지 전송 방법입니다. 센서의 측정 데이터와 같이 한방향으로 지속적인 데이터를 전송할 때 주로 토픽을 사용합니다.
토픽의 이름, 메시지 타입, 메시지로 구성되며, 예를 들어 LiDAR 센서에서 데이터를 전송하면 다음과 같이 구현될 수 있습니다.
- 토픽 이름: /scan
- 메시지 타입: sensor_msgs/LaserScan
- 메시지
토픽은 위 사진과 같이 1:1 이외에도 N:N으로 데이터를 주고받을 수 있습니다. 즉, 여러 노드에서 동일한 토픽으로 데이터를 전송하거나 수신할 수 있습니다.
서비스(Service)
서비스(Service)에 대한 설명은 ROS 2 Jazzy 공식 Docs의 자료를 사용합니다. 보다 자세한 내용은 아래 링크를 참고해 주세요.
앞서 소개한 토픽은 단방향 통신 방법이기 때문에 센서의 데이터를 전송할 때는 편리하지만, 모터와 같은 액추에이터에 사용하기에는 작동 완료 여부를 알 수 없어 사용하기에는 적합하지 않습니다. 이럴 때는 서비스(Service)라는 이름의 양방향 메시지 전송 방법을 사용할 수 있습니다.
서비스(Service)는 서비스를 제공하는 Server와 서비스를 호출하는 Client로 구성됩니다. Client에서 Server로 데이터와 함께 서비스를 요청(Request)하면 Server에서는 데이터를 이용해 특정 동작을 수행한 후 결과 데이터로 응답(Response)합니다.
서비스도 토픽과 유사하게 서비스의 이름, 메시지 타입, 메시지로 구성되어 요청과 응답을 주고받습니다. 예를 들어 모터 속도를 설정하기 위한 서비스는 아래와 같이 구현할 수 있습니다.
Reqest
- 서비스 이름: /motor/set_speed
- 메시지 타입: rcl_interfaces/srv/SetParameters
- 메시지
Response
- 서비스 이름: /motor/set_speed
- 메시지 타입: rcl_interfaces/srv/SetParameters
- 메시지
토픽 메시지는 다수의 Publisher와 다수의 Subscriber가 존재할 수 있었지만, 서비스 메시지는 하나의 Server만 존재할 수 있습니다. 대신 여러 Client에서 하나의 서비스에 요청을 전송할 수 있습니다. 즉, 서비스는 1:N 통신이 가능합니다.
액션(Action)
액션(Action)에 대한 설명은 ROS 2 Jazzy 공식 Docs의 자료를 사용합니다. 보다 자세한 내용은 아래 링크를 참고해 주세요.
액션(Action)은 토픽과 서비스를 반반 섞은 형태입니다. 토픽의 연속적인 데이터 전송과 서비스의 요청, 이 두 가지 특징을 섞었다고 볼 수 있습니다.
기본적인 구성은 서비스처럼 액션 Client가 액션 Server로 목표(Goal)를 전송합니다. 목표를 수신한 Server는 목표가 올바른지 등의 내용을 응답합니다.
Client에서는 목표에 대한 Server의 응답을 받은 후 결과(Result)를 호출한 후 대기합니다.
Result 서비스를 수신한 Server는 목표에 도달할 때까지 피드백 토픽(Feedback Topic)을 통해 데이터를 지속해서 전송합니다. 피드백 토픽은 디버깅이나 현재 상태를 확인하는 등의 용도로 활용할 수 있습니다. 목표에 도달하였다면 결과를 보냅니다.
액션의 특이한 점은 Client에서 Server의 동작을 도중에 끊어버릴 수 있다는 점입니다. 즉, Client에서 목표를 보낸 후 피드백을 모니터링하던 중 동작을 멈춰야 할 것으로 판단이 된다면 동작을 멈추어버릴 수 있습니다.