ros_gz_bridge

Gazebo는 ROS 노드가 아닌데, /scan은 어떻게 ROS에 보일까?

두 세계

Gazebo와 ROS는 말이 다릅니다

Gazebo는 자기만의 통신(gz-transport)과 자기만의 메시지(gz.msgs.*)를 씁니다. 토픽 이름이 같아 보여도 ROS 노드는 Gazebo 토픽을 직접 듣지도, 보내지도 못합니다.

다리

브리지가 양쪽을 번역합니다

ros_gz_bridge 패키지의 parameter_bridge 노드가 한쪽 토픽을 받아 다른 쪽 메시지로 바꿔 다시 냅니다. ROS 쪽에서 보면 이 브리지가 /scan을 발행하고 /cmd_vel을 구독하는 평범한 노드입니다.

설정 파일

무엇을 이을지 YAML에 적습니다

3편의 스폰 런치는 params/turtlebot3_burger_bridge.yaml을 브리지에 넘깁니다. 그 안의 cmd_vel 항목이 ROS의 geometry_msgs/msg/TwistStamped를 Gazebo의 gz.msgs.Twist로 바꾸라고 적고 있습니다. 5편에서 TwistStamped를 보내야 했던 이유입니다.

화면 폭 때문에 타입 값을 다음 줄로 내렸습니다(YAML에서 같은 뜻).

방향

direction이 흐름을 정합니다

burger 설정에는 일곱 항목이 있습니다. GZ_TO_ROS는 Gazebo가 만든 값을 ROS로 올리고, ROS_TO_GZ는 ROS의 명령을 Gazebo로 내립니다. 명령인 cmd_vel만 내려가고 나머지는 모두 올라옵니다.

맨 위 /clock도 브리지로 올라옵니다. 다음 편의 주인공입니다.

엿보기

ROS 쪽에서는 보통 토픽입니다

ros2 topic list -t는 토픽 이름 옆에 타입을 함께 보여 줍니다. 브리지가 올린 토픽은 ROS 쪽에서 다른 토픽과 똑같이 echo하고 구독할 수 있습니다.

출력 일부만 보였습니다.

한 줄 브리지

명령줄로도 다리를 놓습니다

YAML 없이 인자로도 적을 수 있습니다. ros2 run ros_gz_bridge parameter_bridge /clock@rosgraph_msgs/msg/Clock[gz.msgs.Clock은 Gazebo의 시계를 ROS로 올리는 다리 하나를 놓습니다.

TurtleBot3 런치는 이미 /clock을 잇고 있으니, 직접 만든 월드에서 쓰는 방법입니다.

다음 편

브리지로 올라온 /clock은 어디에 쓸까요?

7편시뮬레이터의 시계는 따로 간다 14강 목록