Basic Navigation Tuning Guide

- 원본 : http://wiki.ros.org/navigation/Tutorials/Navigation%20Tuning%20Guide

 

1. 준비

새로운 로봇에서 내비게이션 스택을 튜닝할 때 직면하는 대부분의 문제는 local planner의 튜닝 파라미터 외부의 영역에 있다. 로봇의 odometry, localization, 센서 그리고 내비게이션을 효과적으로 실행하기 위한 다른 사전 요구 사항들에 문제가 있는 경우가 많다. 그래서 제일 먼저 해야할 것은 로봇 자체가 내비게이션이 준비가 되었는지 확인하는 것이다. 이것은 3가지 요소(range sensors, odometry, localization) 점검으로 구성된다

 

1.1 Range Sensors

만약 로봇이 laser와 같은 범위 센서의 정보를 받고 있지 않는다면, 내비게이션의 어떤 것도 작동할 수 없다. 센서의 정보를 rivz에서 볼 수 있는지, 상대적으로 정확한지, 예상 속도(rate)로 들어오는지 확인해야한다.

 

1.2 Odometry

종종, 정확하게 localize를 하는 것에 많은 어려움을 겪을 것이다. 계속해서 길을 잃고, AMCL을 위한 parameter를 만지작거리다가 진짜 범인이 odometry라는 것을 알게 되는 것에 많은 시간을 소비할 것이다. 로봇의 odometry를 확실히 하기 위해서는 2가지의 검사를 실시해야한다.

 

첫 번째 검사는 odometry가 얼마나 회전에 합리적인지를 확인하는 것이다. rviz를 열고, 프레임을 “odom”으로 설정하고, 로봇이 제공하는 laser scan을 표시하고, topic에 대한 decay time을 높게 설정하고 (약 20초), 회전 시켜보자. 그런 다음 scan과 후속 회전이 얼마나 밀접하게 일치하는지 살펴보자. 이상적으로는 scan이 바로 위에 떨어져야 하지만, 약간의 회전 밀림이 예상되기 때문에 1~2도 이상 어긋나지 않도록 해야한다.

두 번째 검사는 번역을 위한 odometry를 확인하는 것이다. 로봇을 벽에서 몇 미터 정도 떨어뜨리고, rviz를 같은 방법으로 세팅하자. 그런 다음 로봇을 벽을 향해 직선으로 움직이고, rviz에서 집계된 laser scan에서 보고한 벽의 두께를 확인해라. 단일 scan으로 보이는 것이 이상적이지만, 두께가 몇 센티미터가 넘지 않도록 해야한다. 만약 벽을 향해 1미터 움직이고, 0.5 미터 이상 펼쳐진 scan을 받는다면, odometry에 이상이 있을 수 있다.

 

1.3 Localization

odometry와 laser scanner 둘다 모두 합리적으로 작동한다고 가정할 때, 지도를 만들고 AMCL을 튜닝하는 것은 일반적으로 어렵지 않다. 먼저 gmapping과 karto를 실행하고, 조이스틱을 이용하여 지도를 생성하자. 그런 다음, 지도를 AMCL과 함께 이용하여 로봇이 localized를 유지하게 한다. 만약 실행한 로봇의 odometry가 좋지 않다면, AMCL의 odometry model parameters를 사용해보자. 전체 시스템에 대한 좋은 테스트는 laser scans와 지도가 rviz의 “map” 프레임에서 시각화되는지, laser scans가 지도 환경과 잘 일치하는지 확인하는 것이다. 또한 작동하기를 기대하기 전에 항상 rviz상에서 로봇의 initialpose(초기 위치)를 적절한 정확도로 설정하는 것을 확인해야한다.

 

 

 

2. The Costmap

로봇이 Navigation을 위한 전체 조건을 충족한다고 판단되면, Costmap이 올바르게 설정되고 구성되었는지 확인해야한다. Costmap을 구성하는 방법에 대한 자세한 방법은  ROS Navigation Tutorial과 costmap_2d documentation에 남기겠지만, 몇 가지 팁은 다음과 같다.

 

- 센서가 실제로 publish하는 rate를 기준으로 각 관찰 소스에 대한 expected_update_rate 파라미터를 설정해라. 센서가 예상 rate 보다 훨씬 낮게 떨어져서 내비게이션으로부터 경고를 받을 경우, 보통 예상하는 것보다 두 배 정도의 period를 두고 tolerance(허용)을 주는 것이 좋다.

 

- transform_tolerance 파라미터를 시스템에 맞게 설정해라. tf를 사용하여 “base_link” 에서 “map” 프레임으로의 transform에 대한 예상 latency(지연시간)을 확인할 수 있다. 보통 시스템의 지연을 확인하고, 파라미터를 적절하게 설정하기 위해 tf_monitor를 사용한다. 또한 tf_monitor에서 보고되는 지연이 충분히 크다면, (latency)지연시간의 원인이 뭔지 살펴봐야한다. 이것은 때때로 주어진 로봇의 transform이 어떻게 publish 되는지에 대한 문제를 찾도록 유도한다.

 

- 처리 능력이 부족한 로봇에서는 map_update_rate 파라미터를 줄이는 것을 고려해라. 그러나 이를 수행할 때, 센서 데이터가 costmap으로 만들어지는 속도가 지연되어 로봇의 장애물 반응 속도가 느려지는 원인이 될 수 있다는 사실을 고려해야한다.

 

- publish_frequency 파라미터는 costmap을 rviz상으로 시각화하기에 유용하다. 그러나 특히 대형 global maps의 경우, 이 파라미터가 작업을 느리게하는 원인이 될 수 있다. production 시스템에서는 costmap이 publish되는 rate를 줄이는 것을 고려하고, 매우 큰 맵을 시각화해야할 때는 rate를 매우 낮게 설정해야한다.

 

- voxel_grid 또는 costmap 모델을 사용할지 여부에 대한 결정은 주로 로봇이 가지고 있는 센서 제품군에 따라 달라진다. 3D 기반 costmap 튜닝은 미지의 공간에 대한 고려사항이 실제로 적용되기 때문에 더 많은 작업이 수반된다. 만약 사용하고 있는 로봇이 평면 laser만 가지고 있으면, 항상 costmap 모델을 사용해야한다.

 

- 때때로, odometric 프레임에서만 단독으로 Navigation을 실행하는 것이 유용할 수 있다. 이렇게 하려면, local_costmap_params.yaml 파일을 global_costmap_params.yaml 파일에 복사하고, 지도의 너비와 높이를 10m 정도로 변경하는 것이 가장 쉽다. 이것은 localization 성능에 관계없이 navigation을 튜닝하려는 경우 작업을 시작 및 실행할 수 있는 매우 쉬운 방법이다.

 

- 로봇의 크기와 처리 능력에 따라 지도의 resolution(해상도)를 선택해야한다. PR2와 같이 처리 능력이 뛰어나고, 좁은 공간에 들어가야 하는 로봇에 대해서는 해상도를 0.025 미터로 설정하여 세밀한 지도를 사용한다. roomba 같은 경우에는 컴퓨터 부하를 줄이기 위해 해상도를 0.1 미터까지 높일 수 있다.

 

Rviz는 costmap이 올바르게 작동하는지 확인하는 좋은 방법이다. 보통 costmap에서 장애물 데이터를 보고, joystick으로 로봇을 움직일 때 map과 laser 모두에 맞춰 정렬되도록 확인한다. 이것은 센서 데이터가 합리적인 방법으로 costmap을 만드는지를 확인하는 것이다. 만약 로봇(대부분 voxel_grid 모델을 이용하는 로봇)으로 미지의 공간을 추적하기로 결정했다면, 미지의 공간이 합리적인 방법으로 정리되고 있는지 확인하기 위해 미지의 공간 시각화를 꼭 살펴봐야한다. costmap에서 장애물이 올바르게 정리되고 있는지 확인하는 좋은 방법은 단순히 로봇 앞으로 걸어가서 로봇이 성공적으로 보고 제거하는지 보는 것이다. rviz에서 costmap에 의해 publish된 토픽에 대한 자세한 내용은 navigation with rviz tutorial에서 확인해라.

 

- navigation stack이 costmap만 실행할 때, 시스템 부하를 확인하는 것이 좋다. move_base 노드는 불러오지만 goal을 보내지 않고 부하만 확인하는 것이다. 만약 컴퓨터가 이 부분에서 정체된다면, planner를 실행하기 위해 CPU 절약 파라미터를 약간 수정해야할 필요가 있다.

 

 

 

3. The Local Planner

만약 costmap을 통한 작업이 만족스럽게 진행된다고 판단되면, local planner 파라미터 튜닝으로 넘어가자. 가속 제한이 합리적인 로봇에서는 일반적으로  dwa_local_planner를 사용하고, 가속 제한이 낮으며 모든 단계에서 가속 제한을 고려하는 rollout의 이점이 있는 경우에는 base_local_planner를 사용한다. 비록 전반적으로 navigation stack에 대한 동적 재구성을 추가하는 것이 roadmap에 있지만, base_local_planner의 매개변수가 동적으로 재구성이 가능하기 때문에 dwa_local_planner를 튜닝하는 것이 base_local_planner를 튜닝하는 것 보다 더 쉽다. planner에 대한 팁은 다음과 같다.

 

- 모든 planner에서 가장 중요한 것은 가속 제한 파라미터가 주어진 로봇에 대해 정확하게 설정되어야 한다는 것이다. 만약 이 파라미터들이 꺼져있다면, 로봇으로부터 차선의 행동을 기대할 수 있다. 만약 로봇의 가속 한계를 모른다면, 일정 기간동안 모터에 최대 변환 속도와 회전 속도를 명령하는 스크립트를 작성하고, odometry로부터 보고된 속도를 보고(odometry가 합리적인 추정치를 제공한다고 가정했을 때), 그로부터 가속 한계를 도출해낼 수 있다. 이러한 파라미터를 합리적으로 설정하면 나중에 많은 시간을 절약할 수 있다.

 

- 만약 작업 중인 로봇의 가속 제한이 낮으면, dwa를 False로 설정된 상태에서 base_local_planner가 실행 중인지 확인해라. dwa를 True로 설정한 후에는 사용 가능한 처리 능력에 따라 vx_samples 파라미터가 8에서 15 사이로 업데이트하도록 확인해라. 이렇게 하면 rollout에서 비원형 곡선이 생성될 수 있다.

 

- 현재 작업 중인 로봇의 localization이 좋지 않은 경우, goal tolerance (목표 허용 오차) 파라미터를 다른 것보다 약간 높게 설정해라. 또한 로봇이 목표 지점에서 왔다갔다하는 것을 피하기 위해 극최소 회전 속도를 가진다면, 회전 허용오차를 높여라.

 

- CPU로 인해 낮은 해상도를 사용하는 경우, sim_granularity 파라미터를 약간 높여 일부 사이클을 절약할 수 있다.

 

- 실제로 planner에서 path_distance_bias와 goal_distance_bias (base_local_planner의 경우 이러한 파라미터를 pdist_scale와 gdist_scale이라고 한다) 파라미터를 변경하는 경우가 많이 없다. 보통 그렇게 하는 경우는  NavFn이 아닌 다른 global planner와 함께 실행될 수 있도록 계획된 경로를 떠나려고하는 local planner의 자유를 제한하기 위해서다. path_distance_bias 파라미터 값을 올리면, 로봇이 목표를 향해 빠르게 이동하는 대신 경로를 더 가깝게 따라갈 수 있다. 이 무게를 너무 높게 설정하면, 이동 비용이 경로 상의 위치에 머무르는 것보다 더 크기 때문에 로봇이 이동하는 것을 거부한다.

 

- 만약 비용 함수에 대해 지적인 방법으로 추론하고 싶다면, meter_scoring 파라미터를 Ture로 설정해야한다. 이것은 비용함수의 거리가 셀이 아닌 미터로 되게하고, 또한 하나의 지도 해상도를 위해 비용함수를 조정할 수 있고, 다른 곳으로 이동할 때 합리적인 동작을 기대할 수 있다는 것을 의미한다. 게다가, publish_cost_grid 파라미터를 True로 설정함으로써 rviz의 local planner에서 생성되는 비용함수를 시각화할 수 있다. 미터 단위의 비용함수를 고려할 때, 계획된 경로와 얼마나 안떨어지고 균형있게 목표를 향해 1미터를 이동하는 비용에 대한 tradeoff를 계산할 수 있다.

 

- 궤적은 끝점에서 매겨진다. 즉, sim_time 파라미터를 다른 값으로 설정하면, 로봇의 동작에 큰 영향을 미칠 수 있다. 이 파라미터을 높게 설정하면 궤적이 약간 부드러워지기 때문에 이 값을 1~2초로 설정하여, 최소 속도에 sim_period를 곱한 값이 목표에 대한 tolerance(허용오차)의 2배 미만이 되도록 한다. 그렇지 않으면, 로봇은 목표 위치로 이동하기보다는 목표 위치 범위 밖에서 회전하는 것을 선호하게 된다.

 

- 정확한 궤적 시뮬레이션은 odometry로부터 합리적인 속도 추정치를 갖는 것에 달려있다. 이것은 dwa_local_planner와 base_local_planner 모두 로봇의 가속 한계와 함께 이 속도 추정치를 사용하여 실현가능한 planning 주기에 대한 속도 공간을 결정한다는 사실로부터 비롯된다. 비록 odometry에서 나오는 속도 추정치가 완벽할 필요는 없지만, 최적의 동작을 얻기 위해서 최소로 근접했는지 확인하는 것이 중요하다.

 

 

 

4. ROS Navigation Tuning Guide

만약 로봇 Navigaiton이 준비됐다면, Kaiyu Zheng의 ROS Navigation Tuning Guide를 참고하여 로봇의 Navigation 동작 최적화 과정을 거쳐야한다.