지도는 지금까지 로봇에게 배경이었다. SLAM으로 만들고, 저장하고, costmap 위에 색칠해 보며 우리는 로봇이 세상을 어떻게 보는지 살펴보았다. 이제 그 지도가 처음으로 명령문이 된다. '여기로 가.'
이 장은 Nav2에서 가장 짜릿한 순간을 다룬다. RViz 위에 화살표 하나를 그리면 로봇이 경로를 계산하고, 장애물을 피해 움직이고, 목표 지점 근처에서 방향을 맞춘 뒤 멈춘다. 겉으로는 클릭 한 번이지만, 안쪽에서는 AMCL, planner, controller, behavior tree, costmap, TF, /cmd_vel이 한꺼번에 맞물려 돌아간다.
목표 이동은 하나의 액션이다
Nav2에서 목표 지점까지 이동한다는 말은 보통 /navigate_to_pose 액션 서버에 NavigateToPose 목표를 보낸다는 뜻이다. 액션은 9장에서 배웠듯이 오래 걸리는 작업에 적합한 통신 방식이다. 목표 이동은 몇 초에서 몇 분까지 걸릴 수 있고, 중간에 남은 거리나 복구 횟수를 알려 주어야 하며, 필요하면 취소도 되어야 한다. 그래서 서비스가 아니라 액션을 사용한다.
NavigateToPose 목표에는 로봇이 도착해야 할 pose가 들어간다. pose는 위치와 방향을 함께 가진 값이다. 단순히 x, y 좌표만 지정하는 것이 아니라, 도착했을 때 로봇이 어느 방향을 바라볼지도 함께 정한다. Nav2의 NavigateToPose 액션은 목표 pose와 선택적인 behavior tree 경로를 입력으로 받고, 실행 중에는 현재 pose, 경과 시간, 예상 남은 시간, 복구 동작 횟수, 남은 거리 같은 피드백을 제공한다.1
흐름을 아주 단순화하면 다음과 같다.
RViz나 프로그램이
/navigate_to_pose액션 목표를 보낸다.BT Navigator가 목표 이동 행동을 시작하고 planner와 controller를 호출한다.
Planner가 global costmap을 보고 전역 경로를 만든다.
Controller가 local costmap을 보며 지금 당장 따라갈 속도를 계산한다.
계산된 속도 명령이
/cmd_vel로 발행되고 로봇이 움직인다.목표 근처에 도착하면 위치와 방향 허용 오차를 확인한 뒤 성공 여부가 결정된다.
이 흐름을 머릿속에 넣고 RViz를 보면, 화면 위의 선과 색이 더 이상 장식처럼 보이지 않는다. 초록색 경로는 planner의 생각이고, 파란색 짧은 궤적은 controller의 다음 발걸음이며, costmap의 부풀어 오른 영역은 로봇이 가까이 가면 위험하다고 판단한 공간이다.
Nav2가 깨어났는지 먼저 확인하기
목표를 보내기 전에 Nav2가 준비되어 있어야 한다. 시뮬레이션이라면 예를 들어 다음처럼 TurtleBot3 데모를 실행할 수 있다. 배포판과 설치 방식에 따라 launch 파일 이름은 달라질 수 있지만, 중요한 것은 로봇, 지도, 위치 추정, Nav2, RViz가 함께 실행되어야 한다는 점이다.
ros2 launch nav2_bringup tb3_simulation_launch.py headless:=False실제 로봇에서는 먼저 로봇 bringup을 실행하고, 별도 터미널에서 지도 파일을 지정해 Nav2를 실행하는 식으로 구성하는 경우가 많다.
ros2 launch nav2_bringup bringup_launch.py use_sim_time:=False autostart:=False map:=/path/to/my_map.yaml
ros2 run rviz2 rviz2 -d $(ros2 pkg prefix nav2_bringup)/share/nav2_bringup/rviz/nav2_default_view.rvizNav2는 lifecycle node를 사용한다. lifecycle node는 노드가 단순히 실행 중인지뿐 아니라, 설정이 끝났는지, 실제로 동작 가능한 Active 상태인지까지 상태를 나누어 관리하는 노드다. autostart:=False로 실행했다면 RViz 왼쪽 아래나 Nav2 패널의 Startup 버튼을 눌러야 Nav2 노드들이 Active 상태로 전환된다. 공식 Nav2 시작 예제에서도 Startup 이후 초기 위치를 지정하고 Navigation2 Goal을 보내는 흐름을 안내한다.2
RViz에 Nav2 패널이 보이지 않는다면 직접 추가할 수 있다.
Panels → Add New Panel → nav2_rviz_plugins/Nav2 Panel
이 패널에는 Startup, Shutdown, 목표 전송, 목표 취소, waypoint 실행, lifecycle 상태 표시 같은 기능이 모여 있다. 특히 처음 실습할 때는 패널의 상태 표시가 빨간색인지 초록색인지 보는 것만으로도 많은 시간을 절약할 수 있다.3
터미널에서도 준비 상태를 확인해 보자.
ros2 lifecycle get /bt_navigator
ros2 lifecycle get /planner_server
ros2 lifecycle get /controller_server
ros2 action listros2 action list에서 /navigate_to_pose가 보여야 한다. 그 밖에도 /compute_path_to_pose, /follow_path, /spin, /backup, /wait 같은 액션이 보일 수 있다. 사용자는 보통 /navigate_to_pose만 직접 호출하지만, 내부에서는 BT Navigator가 planner와 controller, 복구 행동 액션들을 차례로 부른다.
ros2 action info /navigate_to_pose
ros2 interface show nav2_msgs/action/NavigateToPose두 명령은 목표를 보내기 전에 좋은 안전 점검이 된다. 특히 여러 로봇을 namespace로 실행하고 있다면 /robot1/navigate_to_pose처럼 액션 이름 앞에 namespace가 붙을 수 있다. RViz가 보고 있는 namespace와 터미널에서 확인한 namespace가 다르면 아무리 목표를 클릭해도 로봇은 움직이지 않는다.
AMCL에게 출발 위치를 알려주기
저장된 지도 위에서 주행할 때 Nav2는 보통 AMCL로 현재 위치를 추정한다. AMCL은 지도, LiDAR scan, odom을 이용해 '로봇이 지도 어디쯤에 있을 가능성이 높은가'를 계산한다. 하지만 시작하자마자 AMCL이 모든 것을 알아맞히지는 못한다. 로봇에게는 첫 힌트가 필요하다.
RViz 상단 도구에서 2D Pose Estimate를 선택한다. 지도 위에서 로봇이 실제로 있는 위치를 클릭하고, 마우스를 드래그해 로봇이 바라보는 방향을 지정한다. 이 도구는 /initialpose 토픽으로 초기 pose를 발행하고, AMCL은 이 값을 이용해 particle filter를 초기화한다. particle filter는 여러 개의 후보 위치 입자를 뿌려 놓고 센서 데이터와 맞는 후보를 점점 좁혀 가는 위치 추정 방법이다.
초기 pose를 찍은 직후에는 RViz에서 세 가지를 함께 보자.
로봇 모델이 지도 위의 실제 위치와 비슷한 곳에 놓였는가.
/scan의 LiDAR 점들이 지도 벽과 대체로 겹치는가./particlecloud가 넓게 퍼져 있지 않고 로봇 주변으로 모이는가.
조금 틀린 것은 괜찮다. 로봇이 움직이며 scan과 지도 벽을 계속 비교하면 AMCL이 위치를 다듬을 수 있다. 그러나 복도 반대편에 찍었거나 방향을 180도 반대로 지정했다면 문제다. 이 상태에서 목표를 보내면 로봇은 자신이 엉뚱한 곳에 있다고 믿고 길을 찾는다. 사람으로 치면 서울역에 서 있으면서 강남역에 있다고 믿고 길 안내를 시작하는 셈이다.
LaserScan이 지도 벽과 잘 맞지 않으면 목표를 보내지 말고 초기 pose를 다시 찍자. 특히 실제 로봇에서는 지도 작성 당시와 가구 배치가 달라졌거나, LiDAR frame의 TF가 잘못되었거나, map 파일을 다른 환경의 것으로 불러온 경우도 있다.
RViz를 내비게이션 계기판으로 만들기
목표를 보내기 전에 RViz 화면을 제대로 꾸며 두면, 이후 디버깅이 훨씬 쉬워진다. Fixed Frame은 보통 map으로 둔다. 그리고 다음 display들을 추가해 두자.
Map:/map, 저장된 정적 지도를 표시한다.LaserScan:/scan, LiDAR 점이 지도 벽과 겹치는지 확인한다.TF:map,odom,base_link,base_footprint,base_scan같은 좌표계를 확인한다.RobotModel:/robot_description을 이용해 로봇 모델을 표시한다.Map:/global_costmap/costmap, 전역 경로 계획에 쓰이는 costmap을 표시한다.Map:/local_costmap/costmap, 로봇 주변의 rolling window costmap을 표시한다.Path:/plan, planner가 만든 전역 경로를 표시한다.Path:/local_plan, controller가 당장 따라가려는 지역 궤적을 표시한다.Polygon:/local_costmap/published_footprint, 로봇 footprint를 표시한다.PoseArray:/particlecloud, AMCL 위치 추정 입자를 표시한다.
/map이 보이지 않을 때는 QoS 설정을 의심해야 한다. map server는 늦게 구독한 노드도 지도를 받을 수 있도록 transient local durability를 사용하는 경우가 많다. RViz의 Map display에서 Reliability를 Reliable로, Durability를 Transient Local로 맞추면 해결되는 경우가 많다.3
이 계기판은 주행 중 사건을 해석하는 창이다. 로봇이 멈췄을 때 정말 막힌 것인지, costmap이 너무 부풀었는지, TF가 끊겼는지, planner가 경로를 못 만들었는지, controller가 속도 명령을 못 내는지 화면에서 실마리를 찾을 수 있다.
RViz에서 첫 번째 목표 보내기
이제 목표를 보낼 차례다. RViz 상단에서 Nav2 Goal 또는 사용 중인 설정의 2D Goal Pose 도구를 선택한다. 지도 위의 빈 공간을 클릭하고, 마우스를 드래그한 뒤 놓는다. 화살표의 시작점은 목표 위치이고, 화살표 방향은 목표 방향이다.
이때 RViz는 단순한 점 하나를 보내는 것이 아니다. 목표 위치 x, y와 최종 방향 yaw를 포함한 pose를 만들고, 이를 NavigateToPose 액션 목표로 Nav2에 보낸다. Nav2 Panel에서 숫자로 목표 pose를 입력하고 Start NavigateToPose를 누르는 방식도 같은 개념이다. 일부 RViz 도구나 오래된 설정에서는 goal pose를 토픽으로 발행하는 경우도 있으므로, 이 책에서는 Nav2 RViz 플러그인의 Nav2 Goal과 Nav2 Panel의 NavigateToPose 실행을 기준으로 생각하자.
목표를 놓는 순간 화면에서 먼저 전역 경로가 생겨야 한다. 보통 /plan으로 표시되는 긴 선이다. 이 선이 생기지 않는다면 planner가 목표까지 갈 수 있는 경로를 찾지 못한 것이다. 경로가 생긴 뒤에는 로봇 주변 local costmap 위에서 짧은 local trajectory가 움직이고, controller가 이 궤적을 따라가도록 /cmd_vel을 발행한다.
주행 중에 다음 명령으로 속도 명령이 나오는지 확인할 수 있다.
ros2 topic hz /cmd_vel
ros2 topic echo /cmd_vel/cmd_vel의 linear.x가 양수이면 앞으로 가는 속도 명령이 나오고 있다는 뜻이다. angular.z가 양수나 음수이면 회전 명령이 나오고 있다는 뜻이다. 값이 계속 나오는데 로봇이 움직이지 않는다면 Nav2보다 아래쪽을 봐야 한다. 시뮬레이션 시간이 멈췄는지, velocity multiplexer가 다른 명령을 우선하고 있는지, 안전 정지 장치가 걸렸는지, 실제 모터 드라이버가 명령을 받고 있는지 확인해야 한다.
반대로 /cmd_vel 자체가 나오지 않는다면 Nav2 안쪽 문제일 가능성이 크다. controller가 Active 상태인지, local costmap이 업데이트되는지, 목표가 유효한지, 전역 경로가 만들어졌는지부터 확인하자.
터미널에서 같은 목표 보내기
RViz 클릭은 사람이 쓰기 편한 방식이다. 하지만 로봇 애플리케이션을 만들다 보면 프로그램이 목표를 보내야 한다. 예를 들어 병원 배송 로봇은 간호 스테이션 좌표를 읽고, 물류 로봇은 선반 앞 좌표를 읽고, 순찰 로봇은 저장된 waypoint를 차례로 읽어야 한다.
터미널에서도 같은 액션 목표를 보낼 수 있다.
ros2 action send_goal /navigate_to_pose nav2_msgs/action/NavigateToPose '{pose: {header: {frame_id: map}, pose: {position: {x: 1.0, y: 0.0, z: 0.0}, orientation: {x: 0.0, y: 0.0, z: 0.0, w: 1.0}}}}' --feedbackframe_id: map은 목표 pose가 map 좌표계 기준이라는 뜻이다. position.x와 position.y는 지도 위의 목표 좌표다. 방향은 quaternion으로 표현한다. 평면 이동 로봇에서는 roll과 pitch를 거의 쓰지 않으므로, yaw 각도 θ에 대해 z = sin(θ / 2), w = cos(θ / 2)로 생각하면 된다. 예를 들어 목표 지점에서 map의 +X 방향을 바라보게 하려면 z: 0.0, w: 1.0이면 충분하다.
--feedback 옵션을 붙이면 로봇이 이동하는 동안 피드백이 계속 출력된다. 남은 거리, 예상 남은 시간, 복구 동작 횟수는 주행 상태를 읽는 데 특히 유용하다. Clearpath의 Nav2 액션 예제 역시 navigate_to_pose 액션을 장시간 작업 인터페이스로 사용하고, 실행 중 feedback과 완료 result를 확인하는 흐름을 보여 준다.4
배포판에 따라 NavigateToPose의 result 형식은 조금 다를 수 있다. 어떤 버전은 빈 result에 가까운 형태를 쓰고, 최신 문서에서는 error_code, error_msg를 제공한다. 그러므로 책이나 인터넷 예제를 그대로 믿기보다, 지금 설치된 환경에서 다음 명령으로 실제 인터페이스를 확인하는 습관을 들이자.
ros2 interface show nav2_msgs/action/NavigateToPose움직이는 동안 RViz에서 읽어야 할 것들
목표를 보낸 뒤 RViz를 멍하니 바라보면 로봇이 움직이는 애니메이션처럼 보인다. 하지만 조금만 집중하면 Nav2 내부의 의사결정이 보인다.
가장 먼저 /plan을 본다. 이 전역 경로는 global costmap을 기준으로 만들어진다. 벽, 고정 장애물, inflation 영역을 피해서 목표까지 이어지는 큰 길이다. 사람이 건물 지도를 보고 '복도를 지나 오른쪽으로 돌아가자'고 생각하는 단계와 비슷하다.
다음으로 /local_plan을 본다. 이 경로는 더 짧고 자주 바뀐다. 로봇 주변 local costmap을 보고 지금 당장 따라갈 수 있는 궤적을 고른 결과다. 복도 한가운데 갑자기 사람이 나타나면 전역 경로 전체를 바꾸지 않더라도 local controller가 속도를 줄이거나 우회 궤적을 고를 수 있다.
그다음 costmap을 본다. 장애물 주변에는 inflation layer 때문에 비용이 부풀어 오른 영역이 생긴다. 로봇은 검은 벽에만 부딪히면 안 되는 것이 아니라, 로봇 몸체와 안전 여유를 고려해 벽 가까이도 피해야 한다. footprint display를 켜 두면 로봇 몸체가 costmap 위에서 어느 정도 공간을 차지하는지 직관적으로 볼 수 있다.
마지막으로 /cmd_vel을 본다. planner와 controller가 아무리 멋진 경로를 만들어도, 로봇을 실제로 움직이는 마지막 명령은 속도 명령이다. /cmd_vel은 Nav2가 하위 구동계에 말하는 문장이다. '앞으로 0.2m/s, 왼쪽으로 0.5rad/s 회전.' 이 문장이 끊기면 로봇은 멈춘다.
도착했다는 말의 진짜 의미
초보자가 자주 오해하는 부분이 있다. Nav2가 '목표에 도착했다'고 말하는 것은 로봇 중심이 목표 좌표와 수학적으로 완전히 일치했다는 뜻이 아니다. 실제 로봇은 바퀴가 미끄러지고, 센서는 흔들리고, 위치 추정은 조금씩 오차를 가진다. 정확히 x=1.000000, y=0.000000에 멈추게 하려 하면 로봇은 영원히 작은 보정을 반복할 수도 있다.
그래서 Nav2는 goal checker를 사용한다. goal checker는 위치 오차와 방향 오차가 허용 범위 안에 들어왔는지를 판단한다. 대표적으로 xy_goal_tolerance는 목표 위치에서 얼마나 가까우면 도착으로 볼지 정하고, yaw_goal_tolerance는 목표 방향과 얼마나 비슷하면 방향이 맞았다고 볼지 정한다.
예를 들어 다음과 같은 파라미터가 있다면, 목표 위치에서 25cm 이내이고 목표 방향에서 약 0.25rad 이내이면 도착으로 볼 수 있다. 실제 파라미터 위치와 플러그인 이름은 사용하는 Nav2 배포판과 controller 설정에 따라 다르므로 기존 설정 파일을 기준으로 수정하자.
controller_server:
ros__parameters:
goal_checker_plugins: [general_goal_checker]
general_goal_checker:
plugin: nav2_controller::SimpleGoalChecker
xy_goal_tolerance: 0.25
yaw_goal_tolerance: 0.25
stateful: True허용 오차를 너무 크게 잡으면 로봇이 목표 근처에서 대충 멈춘 것처럼 보인다. 반대로 너무 작게 잡으면 목표 앞에서 계속 움찔거리거나 방향을 맞추려고 불필요하게 회전할 수 있다. 특히 좁은 공간에서는 yaw tolerance가 너무 엄격할 때 로봇이 제자리 회전을 시도하다가 footprint와 costmap 제약에 걸리는 경우도 있다.
최대 속도와 회전 속도도 주행 느낌을 크게 바꾼다. max_vel_x가 크면 빠르게 달리지만 local controller가 장애물을 피할 시간이 줄어든다. max_vel_theta가 작으면 방향 전환이 부드럽지만 목표 방향 정렬이 오래 걸린다. 가속도 제한이 너무 낮으면 로봇이 조심스럽게 움직이고, 너무 높으면 실제 로봇에서 바퀴가 미끄러지거나 흔들림이 커질 수 있다.
처음에는 기본값으로 주행해 보고, 그다음 목표 방향을 바꾸어 같은 지점에 여러 번 보내 보자. 목표 위치는 같은데 화살표 방향만 바꾸면 마지막 동작이 달라진다. 어떤 경우에는 목표 근처까지 잘 가다가 마지막에 제자리 회전을 한다. 이것이 바로 목표 pose가 위치와 방향의 조합이라는 증거다.
실패와 복구 메시지 읽기
항상 성공하면 좋겠지만, 실제 로봇은 자주 실패한다. 목표가 장애물 안에 있을 수 있고, 좁은 문 앞에서 local controller가 더 이상 진행할 궤적을 찾지 못할 수도 있다. AMCL 위치 추정이 틀어져 로봇이 지도와 다른 세상을 보고 있을 수도 있다.
가장 흔한 실패는 목표 자체가 나쁜 경우다. RViz에서 목표 화살표를 벽 안쪽, 검은 occupied cell 위, 또는 inflation으로 진하게 칠해진 영역에 놓으면 planner가 경로를 만들지 못할 수 있다. 지도에서는 빈 공간처럼 보이지만 global costmap에서는 로봇 반경과 안전 여유 때문에 갈 수 없는 공간일 수도 있다. 목표는 항상 로봇 footprint가 들어갈 수 있는 충분히 넓은 흰색 영역에 놓아야 한다.
전역 경로가 만들어지지 않는다면 /plan이 새로 생기지 않거나, 터미널에 planning 실패 로그가 나타난다. 이때는 목표 위치, global costmap, static map, unknown space 처리, inflation radius를 확인한다. 지도 위에서 사람 눈에는 이어진 길처럼 보여도, costmap 해상도와 inflation 때문에 통로가 막힌 것으로 계산될 수 있다.
전역 경로는 있는데 로봇이 앞으로 나아가지 못한다면 local controller 쪽을 의심한다. local costmap 안에 장애물이 가득 차 있거나, footprint가 실제보다 너무 크게 설정되었거나, 센서 장애물이 clearing되지 않아 유령 장애물이 남아 있을 수 있다. 이 경우 Nav2는 costmap clear, spin, backup, wait 같은 복구 행동을 시도할 수 있다. feedback의 number_of_recoveries가 증가한다면 로봇이 스스로 상황을 회복하려고 노력 중이라는 뜻이다.
취소는 실패와 다르다. RViz Nav2 Panel에서 Cancel을 누르거나 액션 클라이언트가 목표를 취소하면 결과는 canceled 상태가 된다. 실패는 Nav2가 목표를 수행하려 했지만 조건상 완료할 수 없다고 판단한 경우다. 성공은 goal checker가 위치와 방향 허용 오차 안에 들어왔다고 판단한 경우다. 세 상태를 구분해야 상위 애플리케이션이 올바르게 반응할 수 있다.
문제가 생겼을 때는 다음 순서로 좁혀 가면 좋다.
/navigate_to_pose액션 서버가 보이는지 확인한다.Nav2 lifecycle 노드들이 Active 상태인지 확인한다.
AMCL 초기 pose가 맞고 LaserScan이 지도 벽과 겹치는지 확인한다.
map → odom → base_linkTF가 끊기지 않았는지 확인한다.목표가 occupied cell이나 inflation 영역 안에 있지 않은지 확인한다.
/plan,/local_plan,/cmd_vel중 어느 단계에서 흐름이 끊기는지 확인한다.
이 순서는 무작정 로그를 뒤지는 것보다 훨씬 빠르다. 로봇 주행 문제는 대부분 '목표가 잘못되었는가', '위치 추정이 틀렸는가', '경로가 없는가', '속도 명령이 안 나오는가', '속도 명령은 나오지만 하드웨어가 안 움직이는가' 중 하나로 좁혀진다.
작은 실험으로 감각 익히기
이 장의 실습은 한 번 성공했다고 끝내지 말자. 같은 지도에서 목표를 여러 방식으로 보내 보아야 Nav2의 성격이 보인다.
먼저 가까운 목표를 보낸다. 로봇 앞 1m 정도의 빈 공간을 클릭하고, 전역 경로와 local trajectory, /cmd_vel을 본다. 그다음 같은 위치에 화살표 방향만 반대로 해서 목표를 보내 보자. 로봇은 같은 위치에 도착한 뒤 방향을 맞추기 위해 다르게 움직일 것이다.
다음에는 벽 가까이에 목표를 놓아 본다. 너무 가까우면 planner가 목표를 거부하거나, 경로는 생기지만 마지막 접근이 불안정해질 수 있다. 이때 global costmap의 inflation 영역과 footprint를 함께 보면 왜 그런지 이해된다. 로봇 중심은 벽에서 떨어져 있어도, 로봇 몸체와 안전 여유까지 고려하면 이미 위험 영역일 수 있다.
마지막으로 goal tolerance를 조금 바꾸어 보자. xy_goal_tolerance를 크게 하면 도착 판정이 느슨해지고, 작게 하면 목표 근처에서 더 정밀하게 움직이려 한다. 단, 실제 로봇에서는 너무 작은 값이 항상 좋은 것이 아니다. 정밀함은 센서 노이즈, 바퀴 오차, 제어 주기, 바닥 상태와 함께 생각해야 한다.
목표 화살표 뒤에 있는 시스템
RViz에서 목표 화살표를 놓고 로봇이 움직이는 장면은 단순해 보인다. 그러나 그 뒤에는 지금까지 배운 거의 모든 개념이 들어 있다. 노드는 각자 맡은 일을 하고, 토픽은 scan과 odom과 cmd_vel을 실어 나른다. TF는 map, odom, base_link를 연결한다. AMCL은 현재 위치를 추정하고, costmap은 장애물을 숫자로 바꾼다. planner는 큰길을 찾고, controller는 당장 움직일 속도를 만든다. 액션은 이 긴 작업을 목표, 피드백, 결과로 묶는다.
이제 로봇은 지도 위의 점이 아니다. 목표를 받고, 판단하고, 실패하면 복구를 시도하고, 성공하면 멈추는 하나의 시스템이다. 다음 장에서는 이 시스템의 행동 순서를 더 깊이 들여다본다. Nav2가 언제 경로를 다시 계산하고, 언제 costmap을 지우고, 언제 후진하거나 회전하는지, 그 의사결정의 뼈대인 Behavior Tree를 살펴볼 차례다.
참고
1NavigateToPose Action | Nav2 API Docs
2Getting Started — Nav2 documentation
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.