navigation concepts

https://docs.nav2.org/concepts/index.html#ros-2

Navigation Concepts — Nav2 1.0.0 documentation

 

 

위의 페이지는 아직 mobile robot의 navigation에 대한 개념을 설명해주는 페이지다. ( 아래 사진과 같은 순서이다. )

위의 순서대로 설명한다.

 

---

 

 

1번째 ROS 2

1.ROS 2

• ROS 2는 Nav2를 사용하기 위한 핵심적인 미들웨어이다. 만약에 익숙하지 않다면, ROS 2에 대해서 알아보고 진행하는 것이 좋다.

---

1.ROS 2 - Action Server

• ROS에서의 action server는 오랫동안 task가 실행해야할때 사용하는 방법중 하나이다. 이는 action을 좀 더 광범위하게 사용하게 해주며, 어떠한 경우에는 topic없이 사용할 수 있게 해준다. 따라서 ROS 2개발자는 action server를 이해하는 것이 중요하다. ( action != action server이다. action server는 action을 수행하는 노드라고 생각하면 쉽다. )
• action server와 service server의 차이점
  • action server와 client는 별도의 process or thread에서 장시간 실행할 작업을 호출한다. 그리고 이를 나중에 return받는다.
  • 또한, action이 완료될 때까지 대기하는 것은 가능하지만, action이 완료 되었는지 확인하며 client thread에서 다른 작업을 계속 수행하는 것이 더 효율적일 수 있다. 
  • 그리고 action은 장시간 실행되기에, action server는 client에게 진행 상태( 피드백 )을 제공하기도 한다.
    • feedback은 어떤 형태든 될 수 있으며, request와 result 타입과 함께 ros의 .action파일에서 정의된다.
    • ex) 불도저를 예시로 들자... request는 목표 각도이며, feedback은 남은 각도, 결과는 최종 각도와 성공/실패 여부이다.
    • ex) 내비게이션 예시.... request는 목표 위치, feedback은 경로를 따라서 이동한 시간과 목표까지 남은 거리, 결과는 성공 여부이다.
  • feedback에 대한 결과는 action client에서 callback을 등록해서 동기적으로 수집이 가능하다. 또한 비동기도 가능. ( 대신에 client node를 실행해야함 )
  • nav2에서는 action server를 사용해서, NavigateToPose라는 action message를 통해서 highest level의 behavior tree(BT) navigator와 통신한다.
    또한, BT navigator는 하위 action server들과 통신하여, 경로 계획,제어,복구 작업을 수행한다.
    각각의 action server는 nav2_msgs 패키지 내에서 고유한 .action타입을 사용해서 서버와 상호작용을 한다.

 

---

1.ROS 2 - lifecycle Node and Bond

• lifecycle node는 ros2에서 도입된 개념이다.
• node의 시작,종료하는 과정을 상태( state) 기반으로 관리할 수 있도록 설계되었다.
  • 이를 통해서 ros시스템의 초기화 및 종료를 예측가능하게 만들며, 상업적 활용과 디버깅을 용이하게 했다.
• nav2에서는 lifecycle node framework가 광범위하게 사용되며, 모든 서버가 이를 활용한다. 가능한 경우 모든 ROS 시스템에서 lifecycle node를 사용하는것이 관례이다. ( https://jihong.tistory.com/585에서 lifecycle에 대한 설명 )
• nav2 내에서는 lifecycle node를 감싸는 wrapper인 nav2_util_LifecycleNode를 사용한다.
  • 이 wrapper는 일반적인 애플리케이션에서 lifecycle node의 복잡한 부분들을 많이 감추며, lifecycle manager와의 bond 연결을 포함하여 server가 활성화 된 후에도 계속 활성 상태를 유지하도록 보장한다.
    만약에 server가 충돌시, lifecycle manager에게 알려서 시스템 전체가 심각한 오류를 방지할 수 있게 하여 종료 상태로 전환한다.
    • bond 연결 : ROS 2에서 lifecycle manager와 server간의 연결을 감시하는 매커니즘.

 

 

---

 

2. Behavior Tree

• BT는 로봇의 행동을 계층적이고 논리적인 방식으로 구성하는 구조이다. 본질적으로는 BT는 task를 수행하기 위한 트리 구조를 가지고 았으며, 이 구조는 상위 노드가 하위노드를 통제하면서 로봇의 행동을 정의한다.
• 주요 특징
  • 계층적 구조 ( hierarchy ) : 복잡한 동작을 단순한 하위 동작으로 나눌 수 있다.
  • 재사용성 ( reusabulity ) : '직진' , '후진' 같은 동작은 여러한 상황에서 재사용이 가능하다.
  • 확장성 ( scalability ) : 새로운 동작을 추가해도 전체 구조에 큰 영향을 주지 않는다.
  • 가독성 ( human - readability ) : FSM보다 상태 전이 수가 적어서 사람이 이해하기가 쉽다.
• 왜 BT가 FSM( finite state machine )보다 좋은가?
  • FSM는 state와 transition으로 구성되며, state수가 많아질수록, transition수가 기하급수적으로 증가함.
  • ex) 축구로봇의 경우, 공위 위치에 따라서 모든 상태를 정의하고 전이해야 한다. ==> 복잡하고 요류 발생 가능성이 높음 
    • BT의 경우는 '공을 향에 이동' , '공 찾기'등과 같은 동작을 노드로 분리해서 정의 가능.
      조건과 동작을 조합해서 원하는 행동 시퀀스를 쉽게 만들수있다.

 

• BT의 내부 구성 ( 아래의 노드들로 구성 )
  • 1. Control Nodes ( 제어 노드 ) : 트리의 흐름을 제어하는 중간 관리자 역할. 제어노드들은 자식 노드들을 실행하며 특정 조건에 따라서 결과를 반환함.
    • sequence  : 모든 자식 노드를 순서대로 실행하고, 하나라도 실패하면 전체 실패
      • ex) (공을 향해 이동 -> 공이 가까워졌는지 확인 -> 공 차기....) 앞의 상황중 하나라도 실패시 실패 반환
    • Fallback ( selector )  : 자식 노드를 순서대로 실행하고, 하나라도 성공하면 전체 성공
      • ex) ( 공이 앞에 있는지 확인 -> 공이 왼쪽에 있는지 확인 -> 공이 오른쪽에 있는지 확인 ) 이 중에서 하나라도 성공시 성공 리턴 
    • Parallel : 여러 자식을 동시에 실행 
      • parall은 성공의 기준 수를 설정함. ( 일부 실패/성공을 허용한다. )
  • 2. Decorator Nodes
    • 자식 노드 하나만을 감싸며, 해당 노드의 행동을 제어한다. 단어 그대로 데코레이터 역할을 한다.
    • ex) RetryUntilSuccessful : 자식 노드가 실패할경우 최대 N번까지 재시도
            Inverter : 자식 노드의 결과를 반대로 만단다. ( 성공->실패 , 실패->성공 )
            Timeout : 자식 노드를 일정 시간 내에만 실행하고, 넘기면 실패 처리 
  • 3. Leaf Nodes : 실제로 행동을 수행하거나 조건을 판단하는 노드이다. 트리의 끝단에 위치하며, 실행 가능한 최소 단위이다.
    • Action Node : 실제 동작을 수행
    • condition Node : 특정 조건을 판단 
  • 노드들의 결과값들..
    • success
    • failture
    • running

 

• Nav2에서 BT를 활용하는 방식 
  • 라이브러리 : BehaviorTree.cpp을 사용
  • 동작 방식
    • 1. 노드 플러그인 생성 
    • 2. BT Navigator에 XML 트리 로드 : XML에 정의된 트리 구조를 로드하며, 각 노드 이름에 해당되는 플러그인을 연결 
    • 3. 탐색 시작 시 트리를 따라서 행동 실행 : root node부터 시작하여 자식 node로 내려가며 로봇이 어떤 행동을 할지 결정 
  • 하나의 BT를 다른 BT의 node처럼 사용할 수 있다. 즉, 서브 트리가 가능하다. ==> 이렇게 하면 복잡한 동작도 작은 단위로 분리해서 재활용 가능 

 

 

 

---

3. navigation servers

• planner와 controller는 navigation 작업의 핵심이다. recovery는 로봇이 안좋은 상황에 놓여있을때, 해결을 시도하거나 다양한 형태의 문제를 처리해서, 시스템이 장애에 견딜수 있게 한다. ( 즉, fault-tolerant )
• smoother는 계획된 경로의 품질을 추가로 개선할 수 있다.
• 이번 색션에서는 위에 대한 개념들이 무엇이며, nav2에서 어떻게 사용되는지 알아본다.

 

---

 

3. navigation servers - Planner , Controller , Smoother , Recovery system

• nav2에서는 planner server , behavior server , smoother server , controller server라는 4가지의 액션서버가 존재한다.
  • action server는 여러 알고리즘 plugin을 맵 형태로 호스팅하여 다양한 작업을 할 수 있게 해준다. 또한 알고리즘 plugin들이 출력값을 계산하는데 사용하는 환경 표현( environmental representation )을 호스팅한다.
• planner , smoother , controller server는 런타임 시 사용될 알고리즘의 이름과 유형을 설정할 수 있다.
  • 여기서 말하는 알고리즘의 유형은 plugin ( lib )로 등록된 이름(pluginlib name)이며, 별칭(alias)는 해당 작업을 위한 이름이다.
    • ex) DWB 컨트롤러를 FollowPath라는 이름으로 사용한다고 하자. 이렇게 한다면 DWB에 대한 모든 파라미터는 FollowPath.<param> 형태의 네임스페이스 아래에 배치된다.
  • 위의 3개의 서버는 각각 자신들의 작업에 해당하는 action interface를 제공한다. Behavior Tree가 해당 BT node를 틱( tick )할때, action server를 호출하여 자신의 작업을 처리한다. 
    server내부의 action server callback은 선택된알고리즘 이름( ex. FollowPath )에 따라 특정 알고리즘을 호출한다. 이를 통해서 사용자는 behavior tree에서 사용되는 알고리즘을 추상화하여 다양한 알고리즘 클래스에 매핑할 수 있다.
  • ex) 경로를 추종하는 plugin controller , 충전기에 도킹하는 plugin controller , 동적 장애물을 회피하는 plugin controller, 또는 어떤 도구와 interface하는 plugin controller 등 N개의 plugin을 가질 수 있다. 이렇게 모든 plugin server을 같은 서버에서 관리하면, 매우 비용이 큰 환경 표현 객체를 중복해서 만들 필요가 없어진다. 
• Behavior 서버의 경우, 각 동작에도 고유한 이름이 존재한다.
  • 그러나 각 plugin은 자체적인 action server를 제공하기도 한다.
    • 이는 만들 수 있는 동작(  behavior ) action의 종류가 매우 다양해서 하나의 단순한 interface로 공통화 하기 어렵기 때문이다.
    • 또한 이 behavior server는 controller server에서 실시간 업데이트를 받는 local costmap을 subscribe하여 작업을 수행한다. 이러게 함으로써, 연산 비용이 큰 costmap을 여러번 인스턴스화하는 일을 피할수있다.
  • 대안으로는, BT node는 실제로 action을 호출하는 매우 간단한 plugin이니, 원하는 다른 action type을 가진 다른 action server를 호출하는 새로운 BT node를 만드는것도 가능하다.
    • 그래서 만약 새로운 server를 만든다면, 기존에 제공된 server들의 패턴과 유사하게 새로운 타입과 plugin 인터페이스를 사용해야한다. 그리고 동시에 새 action server를 호출하기 위한 BT node plugin을 새로 작성해야한다.
      • 하지만 이를 위해서 nav2의 repository 자체를 fork하거나 수정할 필요는 없다. 이미 마련된 server와 plugin구조를 폭넓게 활용해서 쉽게 확장하는 것이 가능하기 때문이다.

---

3. navigation servers - Planner

• planner의 역할은 특정 목표 함수값( objective function )을 달성하기 위한 경로( path )를 계산하는 것이다. 이 경로를 알고리즘이나 용어에 따라서 route라고도 부를수있다.
  • 대표적인 예시로는 '목표 지점까지의 경로 계산( start -> goal )'이나 모든 자유 공간을 커버하는 '경로 계산(complete coverage )' 등이 존재한다.
• planner는 'global environmental representation'과 '버퍼링된 센서 데이터'를 활용할 수 있다.
  • planner는 아래의 작업을 위해 사용될 수 있다.
    • shortest path계산 , complete coverage path 계산 , spare or predefined routes에 따라 이동
• nav2에서 planner가 수행하는 일반적인 작업은 현재 위치에서 목표 위치로 유효한 경로를 계산하는 것이다. 하지만 다양한 종류의 계획 및 route를 지원함.

 

---

3. navigation servers - Controllers

• Ros 1에서 'local panner'라고 불리는 controller는, 전역으로 계산된 경로나 로컬 작업을 실제로 추종( follow )하기 위한 방법을 제공한다.
• controller는 local environment representation에 접근해서, 매 주기마다 실행 가능한 제어 명을을 계산하려고 한다. 이때 많은 controller가 로봇을 공간상에서 예측하여, 매 반복마다 로컬에서 가능한 경로를 계산한다.
  • controller는 아래의 작업을 위해 사용될 수 있다.
    • path following , odometry frame에서 감지기를 활용해서 충전 도킹 , 어떠한 도구와 연동
• nav2에서 controller가 수행하는 일반적인 작업은 전역 플랜을 따르기 위해서, 유효한 제어를 계산하는 것이다. 하지만 여기에는 local planner나 controller의 여러 종류가 존재한다.

---

3. navigation servers - Behaviors

• recovery동작은 장애( fault )에 견딜 수 있는 시스템( fault - tolerant system )의 핵심요소이다.
  
  • recovery의 목표는 시스템에서 알 수 없는 상황이나 실패 조건에 대응하고 이를 자동으로 처리하는 것이다.
• behavior 서버 안에는 반드시 revoery 동작뿐만 아니라, 비용이 큰 resource를 공유하기를 원하는 어떤 동작이라도 포함될수 있다. ( 각각은 독자적 API를 가질수있다. )

 

---

3. navigation servers - Smoothers

• planner가 사용하는 최적성 기준은 실제와 비교해서 단순화 되어있다. 그래서 추가적인 경로 개선이 유용할때가 많다.
  • 위와 같은 이유로 smoother가 도입되었으며, smoother는 경로의 꺽임, 급격한 회전 같은것을 완화시키며 징에믈이나 높은 비용 지점으로부터 거리를 더 크게 두는 작업을 수행한다.
  • planner 내부에 이미 smoother가 포함된것과 다르게, 별도의 smoother를 사용하면, 서로 다른 planner와 smoother를 조합하거나, 특정 구간만 smoothing 처리하는 등 세밀한 제어가 가능.
• nav2에서 smoother는 경로를 입력받아서 개선된 경로를 반환한다. 하지만 입력 경로가 다르면, 개선 기준이나 방법도 달라질수있으니, 이 서버에는 다양한 smoother가 plugin형태로 등록될수있다.

 

---

3. navigation servers - Robot Footprints

• costmap에서 로봇의 footprint는 보통 robot_radius를 설정해서 원형으로 표현하거나, 로봇이 원형이 아닐 경우 임의의 폴리곤 형태( footprint )로 정의할 수 있다. 또한 로봇 상태가 변하면서 footprint를 동적으로 업데이트해야 할 때는 costmap의 ~/footprint 토픽을 통해서 폴리곤을 실시간으로 조정할 수 있다.

 

---

3. navigation servers - waypoint following

• waypoint 추종은 navigation system의 기본 기능중 하나이다. 이는 여러 목적지에 도달하기 위해 system이 navigation을 어떻게 사용할지 결정한다.
• nav2_waypoint_follower 패키지에는 특정 작업 실행자를 위한 plugin interface를 갖춘 waypoint following 프로그램이 포함되어있다.
  • 이것은 특정 위치로 이동하여 사진을 찍거나 상자를 픽업 , 사용자 입력 대기 등과 같은 작업을 수행해야할때 유용하다.
• 일반적으로 중앙 집중식 디스패처와 로봇간의 관계에는 두가지 방향성이 존재한다.
  • 1. 로봇은 단순, 디스패처는 똑똑함 ( Dumb robot; smart centralized dispatcher )
    
    • 이 경우는 nav2_waypoint_follower만으로도 상품 수준의 on-robot 솔루션을 제공이 가능하다.
  • 2. 로봇은 똑똑, 디스패처는 단순함 (Smart robot; dumb centralized dispatcher)
    
    • 이 경우는 샘플/개념 증명용이다.
  • 위의 2가지 방식중에 뭐가 더 좋다고는 못하며, 상황에 따라서 적절히 선택해야한다.
• nav2_waypoint_follower는 GPS기반 waypoint following도 지원.

 

---

4. state estimation

• nav2에서는 community standards에 따라서 2가지 주요한 변환 (  transform )을 제공해야한다.
  • 즉, map -> odom변환은 위치 추정 시스템( localization , mapping , slam )이 제공하고, odom -> base_link 변환은 odometry 시스템이 제공한다,

---

4. state estimation - Standards

• rep 105에서 navigation 및 ros 생태계 전반에 필요한 frame과 규약을 정의한다.
  
  • 이 규약을 지키면, 커뮤니티에 존재하는 localization , odometry , slam을 활용가능하다.
  • 즉, rep-105에서는 최소한 로봇의 TF트리는 map -> odom -> base_link -> [센서 프레임들] 형태로 구성해야한다고 한다.
    • ros2에서의 TF2는 시간에 따라 변하는 변환 정보를 표현하고, 동기화된 정보 ( transform 된 정보 )를 얻을수있게 해주는 라이브러리이다.
  • global localization system은 최소한 map -> odom 변환을 제공해야한다.
  • odometry system은 odom -> base_link 변환을 제공한다.
    • base_link를 기준으로 하는 나머지 transform은 일반적으로 static이며, URDF에서 정의합니다.

 

---

4. state estimation - Global Positioning Localization and SLAM

• global positioning and slam의 역할은 최소한의 map -> odom변환을 제공하는 것이다.
• nav2에서는 AMCL을 통해서 정적인 맵에서 particle filter를 사용하는 localization 기법을 제공하고, slam toolbox를 기본 slam 알고리즘으로 제공하여, 로봇의 위치를 추정하고 맵을 생성한다.

 

---

4. state estimation - Odometry

• odometry 시스템은 dom -> base_link 변환을 제공해야한다.

 

---

5. Environmental Representation

• 로봇이 주변 세계를 어떻게 '인식하고' 해당 정보를 어떠한 구조로 '보관'할지 정의하는 것이 environmental representation이다.
• 여러 센서를 통해서 얻은 정보를 하나로 통합하여 planner , controller , recovery와 같은 다양한 로봇 네비게이션 알고리즘들이 활용될 수 있게 한다.
• 왜 environmental representation이 중요한가?
  • 1. central localization
    • 모든 알고리즘이 공통된 기준으로 사용할 수 있는 공유 데이터 구조( map )이 필요하다.
  • 2. efficiency
    • 알맞게 정돈된 환경 정보가 존재한다면, 각 알고리즘이 불필요한 계산을 반복할 필요가 줄어든다.
  • 3. consistency
    • 여러 알고리즘 간 데이터 해석을 통일할수 있어서, 충돌이나 오류를 최소화 해준다.

 

---

5. Environmental Representation - Costmaps and Layers

• Costmap이란?
  • 2차원 grid 형태로, 각각의 cell이 특정한 cost를 가진다...
    
    • ex)
      • unknown 센서로 측정이 안된곳
      • free 이동이 가능한 공간
      • occupied 장애물이 있어서 이동 불가능
      • inflated 장애물 주변 안전 거리 확보를 위해서 추가 비용을 준 영역
  • costmap을 기반으로, planner와 controller가 로봇의 이동을 결정한다.
• layers란?
  • costmap은 여러개의 layer를 겹쳐서 구성할 수 있다. 긱 레이터는 센서 정보를 받아서 장애물, 안전 거리 , 특수 영역 등을 표현한다.
  • pluginlib을 통해서 새로운 layer를 쉽고 유연하게 추가 및 교체를 할 수 있다.
  • ex)
    • obstacle layer : lidar나 lader로 측정된 장애물을 costmap에 표시
    • inflation layer : 장애물 주변에 추가적으로 안전 구역 설정
  • layers는 독립적으로 sensor data를 해석해서 costmap을 갱신한다.
• 최종적인 costmap은 layers를 종합한 결과물이 된다.

---

5. Environmental Representation - Costmap filters

• filter mask : 맵의 특정 영역을 '특별한 규칙'으로 표시해준 지도
• costmap filter : filter mask의 정보를 활용해서, 로봇이 이동할때 특정한 영역에 들어갔을때 동작이나 비용 정보를 다르게 적용하도록 하는 기법
  • costmap layer로 구현되며, filter라고 불리는 이유는 맵에 표시된 정보를 기준으로 로봇 동작에 filtering을 거는것 처럼 동작하기 때문
• ex)
  • 안전 구역 : map상의 특정한 영역을 '진입 불가'로 표시하여, 로봇이 해당 cell을 영구히 장애물로 인식하게 한다.
  • 속도 제한 구역 : '스쿨존은 30 km/s이하로 운행'과 같은 규칙. ( robot이 해당 cell들로 진입시 controller에서 속도 명령을 제한한다. )
  • 선호 경로 : 산업 현장이나 창고에서 로봇이 이동해야할 특정 통로를 마련. ( 해당 영역을 'cost가 낮은' 셀로 설정해서, 이 경로로 주행하도록 유도 )

 

---

5. Environmental Representation - Other Forms

• costmap이외에도 다양한 표현방식이 존재한다.
  • 1. gradient maps ->지면의 기울기와 지형의 높이 등을 표출한다. 이는 로봇의 traversibility 판단에 사용
  • 2. 3D costmaps -> 3차원 공간 정보를 담은 것이며, 더 정확해지나 계산량이 커짐
  • 3. mesh maps -> 지형 표면을 mesh형태로 표현하여 복잡한 구조물이나 장애물을 세밀히 반영 할 수 있다.
  • 4, vector space -> 머신 러닝 기반으로 물체와 사람과 장애물 등을 개별 객체로 감지하고 추적한다. 이는 point cloud대신에 객체 단위로 처리한다.