Andrew L. Nelson, Gregory J. Barlow, Lefteris Doitsidis
위의 논문을 조금 살펴보면, 제목에서도 알 수 있듯이 진화 로봇 분야에서 사용된 적합도 함수에 대한 조사와 그 분석에 대한 내용이 실려 있습니다.
적합도 함수를 7개의 형태로 분류하고 이것들이 사전 지식을 얼마나 활용하는지에 대해서 분석해 놓은 내용도 있고, 현재 제가 주로 살펴보고 있는 로봇 걸음새 생성 문제에 대해 사용된 적합도 함수들에 대한 분석도 담겨 있습니다.
무려 110개에 이르는 참고문헌을 참조하고 있고, 그 내용에 대한 정리가 엄청난 것 같습니다.
현재 진화 연산을 로봇에 적용해서 사용하는데, 적합도 함수의 적합성 여부에 대해서 생각해보시는 분이 있으시다면 참고해보시면 좋을 듯 합니다.
저의 경우에는 이 논문의 분류에 의하면 두 개의 분류에 해당하는 적합도 함수를 섞어서 사용하고 있었더군요. Aggregate, Tailored 의 두 가지 형태의 조합을 사용하고 있었습니다. 위의 논문 덕분에 적합도 함수 자체의 특성에 대해 생각지도 않았던 사실을 알게 되어 좋군요;
MSRS(Microsoft Robotics Studio) 가 정식버전이 나오면서 MSRDS(Microsoft Robotics Developer Studio) 로 이름이 바뀌어 발매가 되었더군요. MSRS 이던 시절부터 이 툴 에 대한 기대는 매우 컸고, 소개나 이런 것들을 봤을때 정말 로봇 연구 분야에 있어서 최적의 툴이 아닌가 생각을 했었습니다.
CCR(Concurrency and Coordination Runtime) 과 DSS(Decentralized Software Services) 를 통해 비동기적 처리 방식에 실시간 반응이 가능하도록 하였고, VPL(Visual Programming Language) 이라는 Labview 와 같은 GUI 형태의 언어를 통해 누구나 쉽게 로봇을 제어할 수 있다는 것을 주로 장점으로 부각하였습니다. 여기에 서비스의 추가만 이루어지면 확장할 수 있다는 것, 사실적인 물리엔진 등등 많은 장점이 부각되고 있었습니다.
뭐... 참 좋은 툴임에는 틀림 없습니다만, 두가지 확실히 눈에 보이는 단점들이 있더군요. 각각에 대해서 한번 간단하게 정리해볼까 합니다.
1. 높은 사양
(*) 저도... 시뮬레이션을 돌리고 싶어요... ㅠㅠ
MSRS 1.5 -> MSRDS 2008 로 넘어오면서 픽셀쉐이더와 버텍스쉐이더를 지원하는 GPU 를 시뮬레이션 환경에서 요구합니다. 물론 고화질의 시뮬레이션을 얻는다는것이 나쁘다는 건 아닙니다. 꼬우면 돈주고 사면되지 않느냐라고 해도 딱히 할말은 없죠. ( 모 게임에서는 돈이 없는건 죄가 아니다라고 하더군요;;; 아..아스트로레인저 잊지않겠다 -_- ) 그러나 MSRS 에서는 분명 소프트웨어적으로도 그런 시뮬레이션 환경을 지원 했었습니다. 그래서 상대적으로 사양이 낮은 PC 에서도 시뮬레이션을 수행해보는데 큰 무리가 없었습니다. 하지만 MSRDS 2008 로 넘어가면서 시뮬레이션 화면자체가 검은 상태로 아무것도 나타나질 않습니다. 제가 알기로는 현재 MSRDS2008 에서 GPU 의 내장 물리 엔진을 사용하는 것도 아닌걸로 알고있습니다만(이부분은 명확하지 않습니다.), 어떤 이유에서인지 반드시 GPU 의 엔진을 요구하고 있습니다. 덕분에 저는 다른 사양 좋은 컴퓨터에서 작업을 해야되지 말입니다..... 그리고 이 높은 사양에 대한것은 하나 우려되는 점이 있습니다. CCR 과 DSS 를 통해 비중앙화된 전송형태와 동시성을 확보할 수 있다고 하는데, 이 역시 멀티코어 기반의 환경을 주로 테스트 벤치마크로서 보여주고 있습니다. 단일 코어 기반은 쓰지 말라는 것 같습니다. -_-
2. VPL
VPL 은 초보자를 위한 언어이고, 간단한 테스트 정도를 위한 언어일 것이라고 생각됩니다. 이를 통해 복잡한 로직을 구현한다는 건 오히려 머리속에 방해가 될 것 같은 기분이 듭니다. 물론 Labview 를 통해 큰 규모의 프로그램을 봤을 때, VPL 도 그러한 가능성을 충분히 가지고 있다고 생각이 됩니다. 그러나 Labview 의 그것에 비해서 VPL 은 생각보다 많이 불편합니다. 일단 깔끔해 보이기 위해서 큼직큼직한 서비스 아이콘을 만든건 좋습니다만, 오히려 좀 더 작고 가볍게 만들어서 쓸데없는 그래픽 효과가 나타나다가 다운먹는 현상을 좀 없애주는건 어떨까 생각합니다. 약간만 흔들어대도 공포의 오류메세지가 나타납니다만 이건 좀 아닌것 같죠? ( 제 PC 에서만 그런 건가 했는데, 그게 아니더군요 -_- ) 그리고 루프를 만드는 것이 상당히 지저분합니다. 아주아주 지저분합니다. 루프의 편의를 제공하기 위해 제공하는 서비스가 있긴 하지만, 그것을 이용한다 해도 지저분한 것은 어쩔 수 없죠. 물론, 그 더러운꼴 보기 싫다면 C#을 사용하면 됩니다.... MSRDS 하나를 사용하기 위해 새로운 언어를 쓰라. 이말입니다. ( 그렇다고 C#이 나쁘다는건 아닙니다. 써보니 편하고 좋습니다;; )
....
그냥 확실한 단점인 저 두가지만 지적해야겠습니다. 저 두가지만으로도 정이 뚝떨어지긴 합니다.( 특히 고사양은 정말... ㅜㅜ ) 물론 범용적으로 알려져 있는 로봇 시뮬레이터가 없고, VPL 로 몇가지 시뮬레이션 로봇을 돌려보시고 나면 정말 이렇게 쉬울수가! 라고 외치실 지도 모릅니다.
하지만... 뭔가 더 해보시려면 발버둥이 아니라 생난리를 쳐도 난감해지는 상황에 봉착하게 될것입니다. (아닐수도 있습니다 ^^) 어디까지나 현재로서는 말이죠. 기본 서비스를 제공하는 것 만으로는 고수준의 시뮬레이션을 하기는 어렵고, 실제 로봇과의 연동을 위해서는 일단 로봇이 필요하지만, 사실상 있다고 해도 이를 지원하는 로봇이 아직까지는 그렇게 다양하지는 않습니다.
C# 을 사용할 수 있고, 배울 수 있는 분이라면 MSRDS 가 가진 가능성은 무궁무진하다는 것만큼은 확실합니다. MSRDS 의 세부적인 서비스 개발에도 C#이 필요하고, VPL 로 할 수 없는 고수준 제어 역시 C#으로만 가능하기 때문이죠.
전체 내용을 정리를 하자면, 1. MSRDS 2008 로 업그레이드 되면서 사양이 무지하게 높아졌다. 그러므로 로우스펙의 유저는 그냥 VPL 로 덧셈뺄셈만 해보면 그걸로 끝, 시뮬레이션은 기대도 말고... ( Simulation Engine 이나 Simulation 관련 서비스 하나만 띄우시고 수행하셔보시면, 사용 가능 여부를 바로 알 수 있습니다. ) 2. VPL 로 많은 것을 기대하지 마라. 그리고 VPL 로 복잡한 프로그래밍을 할 경우에 수시로 저장을 해야 중간에 다운먹어도 당황하지 않을 것이다. 3. MSRDS 2008 의 모든 기능을 사용해 보기 위해서는 C#을 배우세요. C#을 배우면 세상이 달라집니다.
(*) 개인 유저이시라면 가급적이면 불법복제품 쓰지 마시고, Express 버전을 사용하세요. 사실 개인이 Professional 버전 이상의 컴포넌트를 사용할일은 별로 없는것 같아요; Express 버전의 C# 으로도 여러가지 작업을 하는데 크게 부족함이 없었습니다. 대학생이시라면 드림스파크 링크로 가셔서 Professional 버전의 정품을 사용하시는것도 좋습니다 :)
이 글에서는 여러가지 제어방식에 대해 이제까지 제가 찾아보고 알아낸 정보들을 개략적으로 정리해보고자 합니다. 보행 로봇의 걸음제어에 대해 막 입문하시는 분들께 약간의 도움이라도 되었으면 좋겠습니다.
제가 처음에 보행로봇의 걸음제어에 관심을 가지게 된 것은 Aibo 를 이용한 Robocup 대회 관련된 논문들을 살펴보면서 였습니다. 외국의 많은 팀들은 각자 독특한 여러가지 방식으로 로봇의 걸음새(영어로 Gait 라는 표현을 쓰더군요)를 만들었습니다. 처음에 가장 기초적인 프리미티브(Primitive, 적절한 한글 표현이 없는듯 싶네요;;)방식, 그리고 역기구학 해석을 통한 발자취의 제어 형태, 수학적 알고리즘을 통한 발자취 제어의 최적화 방식, 가장 최근에는 진화연산을 이용한 발자취 파라미터의 최적값을 찾아내는 방식에 이르기까지 상당히 많은 형태의 제어방식이 있습니다.
?
1. 프리미티브(Primitive) 제어 방식
처음 제가 생각했던 걸음을 만드는 방식은 강아지가 걸어가는 것을 참고로해서 일일이 각각의 각도 값을 전부 기록해서 일종의 리스트로 표현하고 이것을 연속적으로 움직이는 것이었습니다. 이것은 일반적으로 프리미티브 제어라고 하죠. 하나의 프리미티브는 하나의 동작을 의미하게 됩니다.
이를테면 한걸음 앞, 한걸음 뒤, 좌로 30도, 우로 30도 이런식의 정의를 합니다. 그리고 각각의 정의에는 해당하는 움직임에 대한 각도값들의 리스트를 저장해놓습니다. 실제 이용시에는 한걸음 앞을 호출하면 딱 한걸음만 앞으로 가는 그런 형태를 이용하는 것 입니다.
가장 기초적인 제어방식이고 구현도 어려울것이 없습니다.(물론 관절값을 직접 입력할 수 있는 경우에만 그렇습니다.) 그러나 불확실한 환경에 대한 적응력이나 움직임에 대한 오차보정등이 전혀 고려되지 않았다는 단점이 있습니다. 아주 정밀한 모터를 사용하는 로봇이라면 그래도 어느정도 적용에 있어서 그 오차등이 적긴 합니다만, 이 방식을 통해 정밀한 제어는 사실상 매우 어렵습니다.
?
2. 역기구학 해석을 통한 발자취의 제어 형태
이 방식은 로봇을 연구하는 연구자들의 가장 일반적인 형태의 방식입니다. 제가 이 방식을 처음 본 것은 Robocup 출전팀중 rUNSWift 팀의 2002년 리포트[1]에서 였습니다. 처음 4족 보행 로봇의 제어에 대해 접하신다면 정말 참고할만한 자료가 많습니다. 거의 모든 자료를 공개해놓았기 때문에 실제 이 팀에서 쓴 제어기도 이용해볼 수 있구요.(물론 Aibo ERS-7 모델을 가지고 계실 경우에 그렇다는 말입니다;;)
그리고 아래의 [2] 논문에서는 로봇의 발자취는 사각형으로 고정시킨 상태에서 좌우의 Phase 를 어떻게 조절하느냐에 따른 속도 차이나 이런것에 대한 분석을 해 놓았습니다. 실제 좌우 Phase 의 영향은 로봇의 방향 조절이나 그 속도면에서 어느정도 차이를 보여주는 것으로 알려져 있습니다.
위의 두 자료에서 걸음의 제어에 이용한 방식은 다음과 같습니다. 우선적으로 역기구학 해석을 통해 몸통에 대한, 혹은 전역 좌표계에 대한 발끝의 상대적인 좌표값을 구합니다. 그리고 그 좌표값이 그리는 자취의 도형을 결정하고, 실제 걸음에 적합한 자취의 좌표값을 구합니다. 그리고 그 자취를 통한 걸음의 제어를 수행합니다.
여기서 역기구학 해석이란 아시는 분은 잘 아시겠지만 간단하게 설명하겠습니다. 로봇의 다리는 다수의 관절로 이루어져 있습니다. 이 로봇의 다리가 만약에 3개의 관절로 이루어져 있다고 생각해 보죠. 만약에 로봇의 어느 한 관절이라도 움직인다면, 로봇의 발 끝의 좌표는 그것의 영향으로 변하게 됩니다. 즉, 발끝과 관절들은 상호간의 어떤 관계로서 정의할 수 있다는 말 입니다. 그리고 기구학 해석이란 관절들의 값을 이용해서 발끝의 전역 좌표계상의 위치를 구해내는 것이고, 역기구학 해석이란 발끝의 전역 좌표계상 위치를 통해 현재 관절들의 값을 역으로 해석해내는 것을 말합니다.
발자취를 통한 제어를 이용할 경우에는 로봇을 원하는 방향으로 원하는 만큼 조절하는 것이 가능합니다. 이것이 발자취를 통한 제어의 최대 장점입니다. 게다가 어떤 특정 환경에 대해 가변적으로 움직임을 조절하는 것도 가능합니다. 고로 일반적인 로봇축구 팀들이 가장 많이 쓸 수 있는 방식입니다. 프리미티브 방식에 발자취를 이용한 제어를 결합시킨 형태를 주로 이용합니다.
그러나 이 방식에는 결정해야할 문제가 많습니다. 예를들면 발자취의 도형이나 그 도형의 크기, 도형을 순환하는 속도, 사용할 역기구학의 해석등 상대적으로 많은 문제를 가지고 있습니다. 그래서 가장 처음에는 주로 가장 단순화시킨 직사각형의 형태를 이용하는 것이 대부분입니다. 그리고 역기구학 해석도 yaw, roll, pitch 를 사용해서 행렬로 해석하는 방식을 이용하거나, 기본적인 삼각함수와 거리 함수를 통한 조합을 이용하는 등 어떤 것을 사용할 지 정해야 합니다. 역기구학도 오차나 사용 불가 각도 같은 것도 고려해 줘야 하기 때문에 이것 또한 어떤 걸 쓸지 결정해 주어야 합니다. 그렇기 때문에 수학적 방식을 통한 최적화나 진화연산을 통한 최적화 기법을 이용하곤 합니다. (물론 역기구학의 해석에는 이를 이용할 수 없지만, 도형의 순환속도나 크기 등을 결정하는 데에는 상당한 도움을 줍니다.)
?
3. 수학적 알고리즘이나 진화 알고리즘을 통한 자취의 최적화
위에서 설명한바와 같이 자취를 이용하는 방식에서는 결정해야할 파라미터가 너무 많기 때문에 이를 해결해주기 위해 가장 처음 시도 되었던 방식이 바로 수학적 알고리즘 입니다. [3]논문에서는 Powell’s (direction set) method for multidimensional minimisation 방식을 통해 직사각형의 자취에서 가변적인 형태의 사각형을 사용하게 되었습니다. 즉, 실제 사각형은 최적의 값으로 적합하지 않다는 것이 처음으로 나타나게 된 논문이라고 할까요? 물론 처음이 아닐수도 있습니다만, 이 이전에 나타난 대부분의 논문들에서는 정적인 사각형을 이용하곤 했습니다. 이에 이어 rUNSWift 팀이나 German team[3-5] 등 다른 로봇축구 팀이나 게이트를 연구하는 사람들은 타원형이나 기울어진 타원, 3차원 공간에서의 다각형, 3차 스플라인 함수로 보간된 도형 등을 이용하게 되었습니다.
어떤 도형을 이용하는지도 문제지만, 그 도형의 크기나 순환 속도 역시 큰 문제가 됩니다. 순환 속도는 너무 짧다면 실제적으로 그 도형과 비슷하게 움직이지 않으므로 너무 짧은 형태의 불규칙적 순환형태로 변질되고, 너무 길경우에는 말 그대로 움직임이 굼뜬 거북이마냥 느리게 되죠. 도형의 크기 또한 해당 로봇의 다리가 커버할 수 없는 크기 정도로 클 경우에는 너무 큰 동작을 수행하려고 해서 로봇의 움직임이 예측 불가능이 되기도 하고, 순환 속도와 크기가 복합적으로 작용해서 전혀 예측하지 못한 형태의 움직임이 나타나기도 합니다.
그러므로 이 문제는 상당히 많은 변수를 지닌 복합적인 문제로서 그 해결에 GA 나 ES 등의 진화 알고리즘을 사용하게 됩니다. GA 나 ES 는 제 다른 포스팅에서도 많이 있듯이 다양한 변수를 가진 문제의 최적화 기법으로서 많이 이용됩니다. 가장 중요한 점은 GA 나 ES 에서는 준최적화된 값도 제공하기 때문에 이것을 이용할 경우에도 사람이 손으로 조작한 값보다는 꽤 향상된 형태를 보여준다는 것이죠.
?
4. 다른 형태의 보행로봇의 수많은 제어기법
위에서 설명한 방식들외에도 상당히 많은 제어기법이 존재합니다. 위에서 설명한 방식은 각도 자체를 제어하기 보다는 역기구학을 통해서 점에서 각도를 제어하는 형태의 방식이죠. 그러나 각도 자체를 직접적으로 제어하는 기법들도 있습니다.
이를테면 아래의 포스팅에서 간접적으로 소개했던 CPG를 사용한 방식이 있습니다. 이는 두개의 뉴런의 상호작용을 통해 반복적인 비선형 신호를 발생하는 것을 모델화해서 이용하는 것으로서 비선형 신호 자체가 로봇의 관절값을 나타냅니다. 이것을 이용하게 되면 실제 사람이나 동물이 움직이는 것과 같은 아주 부드러운 형태의 움직임이 가능합니다.
그리고 신경회로망을 이용해서 각 로봇의 관절값을 입,출력으로 이용해서 Controller 형태의 보행 제어 기법이 있습니다[6]. 이 논문에서는 로봇의 관절값이 좌, 우 대칭으로 순환한다는 점을 착안해서 신경회로망을 그에 대응하는 모듈형태로 구성해서 제어에 이용한 기법이 사용되었습니다.
또한, 제안한 기법으로는 Genetic Programming 을 사용해 일정한 수학적 함수를 만들어내고 이를 토대로 로봇의 걸음새를 만들어내는 형태의 기법이 있습니다[7]. 네개의 멀티트리 기법을 통해서 각각의 트리는 각각의 관절 자체가 그리는 궤적을 의미하고, 이를 순환적으로 반복해서 로봇의 걸음을 진화시키는 기법이었는데, 최적화 형태의 접근방식입니다. 장점이라면 직선 거리를 이동하는데 있어서 최고의 속도를 기록할 수 있다는 것이지만, 단점이라는 실제적인 제어의 형태에서 적용하기가 어렵고, 외부 환경에 대한 적응성을 갖기 어렵다는 것이 있습니다.
?
5. 마치면서
보행로봇의 최고의 장점은 역시 걸어간다는 것입니다. 걸어간다는 것은 바퀴로봇과는 달리 계단을 오르거나 장애물을 건너가는 등의 장점을 가질 수 있죠. 그러나 역시 바퀴보다는 느린 속도가 가장 큰 단점이죠. 걸어간다는 것에 속도까지 더해져서 가장 이상적인 형태의 걸음걸이를 만든 다는 일은 완전한 직선형태의 스커트라인을 갖는 필터를 설계하는 것 만큼이나 어려운 일일겁니다. 그러나 역시 안되는 일을 되게 하는것이 공학자들이나 여러 과학자들의 몫이겠죠. 여기서 소개한 걸음 걸이들에 대한 여러가지 이론들은 빙산의 일각이라 할 정도로 수많은 걸음 걸이에 관련된 이론들이 존재합니다.
이제 막 보행로봇의 걸음에 대해 관심을 가지시는 분들에게는 약간이나마 도움이 되었으면 좋겠습니다. 저 역시 아직 부족한 점도 많고, 더 새로운 이론의 적용과 구성을 위해 노력하는 입장이지만, 그래도 조금이라도 도움이 된다면 좋을것 같네요.
[2] D. Golubovic, H. Hu, Parameter optimisation of an evolutionary algorithm for on-line gait generation of quadruped robots. In Proceedings of IEEE International Conference on Industrial Technology ? ICIT’03, Maribor Slovenia December, (2003)
[3] M. S. Kim and W. Uther Automatic gait optimisation for quadruped robots. In Proceedings of the Australasian Conference on Robotics and Automation, Brisbane, Australia, December, (2003)
[4] T. R¨ofer, T. Laue, D. Thomas. Particle-Filter-Based Self-Localization Using Landmarks and Directed Lines. In RoboCup 2005: Robot Soccer World Cup IX, Lecture Notes in Artificial Intelligence, Springer, (2005)
[5] T. Mericli, H. L. Akın, C. Mericli, K. Kaplan, B. Celik, The Cerbus'05 Team Report
[6] V. K. Valsalam, R. Miikkulainen, Modular Neuroevolution for Multilegged Locomotion. In Proceedings of Genetic and Evolutionary Computation Conference 2008 (GECCO 2008), Atlanta, Georgia, USA, July 12-16, pp. 265-272 (2008)
[7] 서기성, 현수환,관절 공간에서의 GP 기반 진화기법을 이용한 4족 보행로봇의 걸음새 자동 생성, 제어·자동화·시스템공학논문지 - Vol.14, No.6 , (2008)
"Central pattern generators (CPGs) can be defined as neural networks that can endogenously (i.e. without rhythmic sensory or central input) produce rhythmic patterned outputs" [1] or as "neural circuits that generate periodic motor commands for rhythmic movements such as locomotion."[2] CPGs have been shown to produce rhythmic outputs resembling normal "rhythmic motor pattern production" even in isolation from motor and sensory feedback from limbs and other muscle targets. [1][2] To be classified as a rhythmic generator, a CPG requires: 1. "two or more processes that interact such that each process sequentially increases and decreases, and 2. that, as a result of this interaction, the system repeatedly returns to its starting condition.[1]
CPG는 내부적으로 반복적인 패턴의 움직임을 만들어내는 것 또는 운동과 같은 것들의 리듬이 있는 움직임을 위해 주기적인 모터에 명령을 만들어내는 신경 회로망으로 정의할 수 있다. CPG 가 리듬을 생성해내는 것으로서 분류되기 위해서는 (1) 두 개 혹은 그 이상의 처리과정이 서로의 처리과정에 대해 연속적으로 증가하거나 감소하는 것 같이 영향을 주어야 하며, (2) 그런 상호작용의 결과로서 시스템은 반복적으로 초기의 상태로 되돌아 갈 수 있어야 한다.
말의 뜻이 잘 전달 되었는지는 모르겠습니다만,? (오역이 있을수도 있으므로 한번 검토해주시면 감사드리겠습니다 ^^)
?
두 개 이상의 처리과정이 조합되어 서로간에 영향을 주어야 한다는 것이 키 포인트 입니다.
즉, 기존의 단순한 sine파형 발생기나 cosine 파형 발생기를 CPG라고 명명할 순 없다고 볼 수 있겠습니다.
?
로봇이 걸어가는데 단순히 sine, cosine 파형만으로도 걸어갈 수는 있습니다.
그에 따른 feedback 응답으로도 물론 보행로봇이 외부환경에 적응해 나가도록 할 수도 있습니다. 하지만 이녀석은 자연스러운 움직임을 보여주지는 못하죠.
?
그래서 이 CPG 라는 것이 눈길을 받게 되었습니다.
CPG라는 녀석을 통해 보행로봇의 걸음새의 모델을 만들어내면, 인간이 걷는 것과 같이 자연스러운 걸음새도 가능하고,
외부 환경의 변화에도 적응할 수 있는 특징을 가질 수 있기 때문입니다.
* 이에대한 깊은 이해는 여기서 다루지는 않겠습니다. 이 부분은 CPG 관련 논문이나 자료들을 참고하시면 좋을것 같습니다.
?
CPG 를 이용해서 실제적인 걸음새가 만들어지는 것은 다음의 사이트를 참고하시면 도움이 될 것 같습니다.
음... 회사에서 물건팔기 위한 거대한 전시장의 느낌?! ... (사실 그게 목적이잖아!! 라고 해도 좀 아쉬운 것도 있었고, 즐겁기도 했던 그런 전시회 였습니다. 로봇에 관심이 있으신분들이라면 가볼만한 전시회라고 생각됩니다. 로봇워 행사도 있었습니다만, 그 부분은 제가 큰 관심이 없어서 그냥 한바퀴 돌아보고 나왔습니다. 딱 한마디로 표현하자면, "볼만하고, 즐겁고, 비싸지않은(!), 하지만 조금은 아쉬운(?) 전시회 입니다."
어제 본 것들을 한번 싹 정리해 봐야겠네요. 은근히 동영상을 많이 찍었더군요.
이것은?! 죄송합니다. -_- 핸드폰카메라로 촬영할때 옆으로 찍으면 저렇게 될거라는걸 생각하질 못했습니다. 카메라가 누운거지 애가 누워서 버티는게 아니랍니다. 처음 들어가서 본 로봇이었습니다. 손을 흔들면서 인사를 하더군요. 사실 이것저것 자기 소개가 많았는데, 어떻게 마지막 인사하는 부분만 찍게되었습니다.
개인적으로 가장 인상 깊은 제품이었습니다. 보시면 카메라 아래쪽이 계속 흔들리고 있습니다. 위에 모니터 왼쪽에 나타나는 화면은 보정이 되기전이고 오른쪽에 나타나는 화면은 보정이 된 후의 화면입니다. 떨림현상이 저렇게 심한데 저걸 저정도로 잡아준다는게 놀라웠습니다. 근데 이걸 로봇이라고 해야하나?... 아래쪽 모니터에 살짝 제 모습도 잡히는군요 -_-
화재 진압 로봇이라고 하더군요. 이런게 좀 더 보급되어서 소방관님들이 좀 더 편한환경에서 일하셨으면 좋겠네요. 사실 제가 가장 기대했던건 이런 녀석같이 위험한 환경에서 좀 더 안전하게 일을 할 수 있는 것을 도와주는 것들이었습니다.
....
로봇에 관심을 두기시작한 이후에 로봇에 대한 지식이 조금이라도 쌓인 후에 보니까 그나마 제품들이 대단하다고 내세우면 그게 왜 대단한지 이해가 가더군요. 어렸을 적에는 그저 태권V나 청소용 로봇들만 대단해보였습니다만, 지금은 매니퓰레이터나 모터들에 대해 좋은거라고 할 때 그게 왜 좋은지 이해가 가니까 한층 더 재미있게 관람했던 것 같습니다.
약 두시간 정도는 정말 재미있게 돌아다녔습니다만... 3시간 이후는... 다..다리가 저리고... 여기저기 브로슈어들을 챙기다보니.. 그게 한 짐짝되고.. 사람 아주 죽겠더군요 ...;;;
로봇에 대해 정말 아무런 지식도 없다면, 사실 몇몇 부스들(청소용로봇이나 안내시스템, 그리고 탑승형 로봇모델들) 외에는 아무 관심이 안갈 수도 있겠습니다.
크게 4종류의 로봇들로 나눌 수 있는데, 휴머노이드! 매니퓰레이터 청소용로봇 안내시스템 이 있습니다만, 여기서는 매니퓰레이터쪽이 엄청 많더군요. 전혀 지식이 없으신 분들은 크게 관심을 못 가지실 수도 있었을 것 같네요. 그게 좀 아쉬웠습니다. (뭐... 아닐 수도 있습니다만 ^^
개인적으로 휴머노이드쪽에는 크게 관심을 갖지 않았습니다. 근데... 어떤 여성모델 로봇이 있었는데... 저 처음에 그거 사람인줄 알았었습니다 -_- 뭔가 어...어색해서.... 자세히보니까... 사람이 아니더군요;; 분명히 사진을 찍어둔 것 같은데 사진이 없네요. 아쉬워라..ㅠㅠ
그리고 몇몇 부스의 살것도 아닌데, 뭘 그러고 있냐는 식의 태도는 솔직히 매우 많이 짜증이 났습니다만... 다음 전시회에서는 저런 태도를 보이는 부스는 차라리 없애버리는게 나을것 같습니다.
오랜만에 정말 즐거운 나들이였습니다. 매일같이 학교 집 학교 집, 혹은 술집 -_- 이었습니다만 역시 이런걸 자꾸봐야 새로운 아이템도 떠오르고 그럴 것 같네요.
이 전시회가 아마 오늘까지 였나요? 지금이라도 늦지 않으니, 로봇에 관심있으신분은 꼭 한번 가서 보시면 좋을것 같네요. (저 홍보위원이나 이런거 전혀 아니랍니다;
Webots 을 이용해 보신 분들이라면 아시겠지만 Webots 내부에서 제공되는 에디터를 이용해 프로그램을 작성하는게 여간 불편한게 아닙니다.
메뉴얼에 이미 있는 내용이지만, 한번 다시 정리해 보겠습니다. 순서대로만 따라서 하면 아주 쉽게 이용하실 수 있습니다.
1. 새로운 Project 생성
위의 그림에서 보이듯이 New 를 눌러서 새로운 Project 를 생성해 줍니다.
2. Project 생성(세부)
Win32 Console Application 을 선택해 주신 후, Project name 에 이용하실 Controller의 이름을 넣어줍니다.
3. Project Settings
그리고 Project 가 생성된 후 Project -> Settings 메뉴를 통해 설정을 해 줍니다. 저 메뉴를 누르게되면 아래와 같은 화면을 보게 됩니다. 이 화면에서 왼쪽에 보이는 최 상위 노드(testController) 를 선택하게 되면 아래와 같은 탭들을 보실 수 있습니다.
4. Debug 설정
Webots 메뉴얼을 보시게되면 기본 Release 상태만 남겨놓고 Debug 를 지우라는 말이 있습니다. 하지만 그렇게 하게되면 실행 도중에 발생되는 문제들에 대해 디버그를 해볼 수가 없습니다. 그렇기에 그냥 그 부분은 무시하시고, Debug 탭을 선택하시면 Executable for debug session: 부분의 Debug\ 부분만을 지워 줍니다. 결론적으로 c:\.....\testController\testController.exe 가 되겠죠.
5. 전처리기(Include) 설정
위와 같이 C/C++ 탭을 누르시고 Category 를 Preprocessor 로 변경하시면 Additional include directories : 부분이 있습니다. 이부분에 c:\Program Files\Webots\Include 를 추가해 주시면 됩니다.
6. Link 설정
Link 탭을 눌러보시면 Output file name 이 있습니다. 이것을 Debug/testController.exe 로 되어있는 것을 testController.exe 만 남기고 지워줍니다. 그리고 아래와 같이 Object/Library modules 부분에 controller.lib 를 추가해 줍니다.
7. Link 설정 (Library Path Link)
마지막으로 Category 를 Input 으로 변경하신 후, c:\Program Files\Webots\Lib 를 Additional library path 에 추가시켜 주시면 Webots 의 Controller 를 컴파일 하실 준비가 끝납니다.
(*) 마치며..
위의 작업을 다 끝내게 되면 기존에 Webots 환경에서 이용하던 Controller 파일을 그대로 VS 6.0 에서 컴파일하고 이용하실 수 있습니다. 그리고 오류가 생기면 디버깅까지 할 수 있기에 작업하실때, 리눅스로 이용하시는 것이 아니시라면 위의 방식을 이용하시는게 더 편한 작업을 하실 수 있을 것입니다.
이렇게 두가지 방법이 있는데 제가 테스트 해본 바로는 신뢰성이 Physics Controller 가 더 높아보입니다.
Aibo ERS-7 의 Trajectory 를 구성하고 로봇이 실제 움직이는 모양이 Trajectory 와 어느정도 비슷한지를 평가하기 위해 Supervisor Controller 의 supervisor_field_get 함수를 이용해서 값을 추출해 봤는데 좌표값이 제대로 매칭이 안되는 것으로 판단됩니다.
로봇의 루트 노드를 타겟으로 잡고 값을 추출 할 때는 매칭이 되지만 하나의 일부 노드를 타겟으로 잡고 값을 추출 할 때는 제대로 매칭이되지 않는 것 같습니다.
반면에
Physics Controller 에서 ODE 라이브러리의 dBodyGetPosition 함수를 통해 값을 추출했을때는 로봇의 위치와 추출된 좌표값이 제대로 매칭이 되는 것으로 판단됩니다.
그리고 상대적 좌표값으로 변환했을 때, 나타나는 점들의 자취또한 Physics Controller 를 이용해 추출해 낸 값들에서 더 올바른 형태가 나타났습니다.
정리해보면
로봇이 현재 위치한 포인트를 잡아내는 방법은 두가지가 있는데 Physics Controller 의 dBodyGetPosition 이 있고, Supervisor Controller 의 supervisor_field_get 이 있는데,
로봇의 한 노드의 포인트를 잡아내기에는 Physics Controller 를 쓰는것이 더 좋고, 현재 로봇의 루트노드의 포인트를 잡아 위치한 곳을 판단하기에는 Supervisor Controller 를 이용하는 것이 더 편합니다.
