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을 잇고 있으니, 직접 만든 월드에서 쓰는 방법입니다.
다음 편