로봇용 소프트웨어 플랫폼 최신 동향 관련
* 로봇용 소프트웨어 플랫폼 최신 동향 관련
본 글은
현재는 로봇 쪽에 종사하지 않더라도
로봇 쪽 소프트웨어 개발에 관심있는 분을 위해 써 보는 글입니다.
로봇이 어쩌구 시장 전망이 저쩌구 하는 이야기는 집어치우고,
'범용 서비스 로봇'이라는 놈을 가정할 경우
이것을 위해 필요한 소프트웨어 개발 분야가 있다고 할 수 있습니다.
물론 로봇의 하드웨어 플랫폼은 별도로 개발되어 있다고 가정하고요.
다른 말로 상위제어 부분이라고 하겠죠.
최근 수년간 동향을 보면,
이 상위제어 부분에 대해서 여러 나라와 단체에서 각자 표준화를 시도해오고 있습니다.
물론 최종 승자가 누가 될지 모르겠지만,
이전의 컴퓨터 세계에서도 그랬듯이
유력한 소수의 소프트웨어 표준만이 살아남아
미래의 로봇산업을 지배하게 될 것으로 추측됩니다.
따라서 이 소프트웨어 표준을 선점하는 것이 아주 중요한 문제가 되겠지요.
뭐든지 간에 플랫폼, 인프라를 선점해야 그 산업을 장악할 수 있으니까요.
신기하게도,
우리나라는 이 일을 상당히 일찍부터 시작했습니다.
정보통신부가 있을 때 RUPI 과제를 2006년부터 아주 진지하게 시작해 들어갔으니까요.
세계적으로도 정말 빠른 편인 것 같습니다.
그런데 약간 삽질을 좀 한 것 같아요.
같은 성격의 과제를, 정통부 RUPI[루피]와 산자부 SPIRE 과제로 각각 따로 진행해서 문제가 되었었죠.
중복투자니까요.
그러다가 참여정부 말기에, 이런 문제점을 해결하기 위해 서바이벌 형식으로 경쟁을 붙이다가
정권이 바뀌고 말았는데 실용정부에서는 서바이벌 형태를 취하지 않고
통합 형태로 모양새를 좋게 만든 모양입니다.
그래서 지경부 OPROS[오프로스] 과제가 되어서 계속 진행되어 왔죠.
이제 2011년도 끝나가니, 개발 이력도 대충 5년 넘어가는 거죠.
목표했던 왠만한 건 다 구현되었고
세계적으로도 이정도로 방대하게 구현된 것이 잘 없어서 자랑할 만 했고
안정성 확보 및 실용화 단계로 접어들고 있는데
복병이 나타납니다.
미국에서 갑툭튀한 Willow Garage[윌로우 개라지]라는 회사에서
ROS 라는 놈을 발표한거죠.
윌로우 개라지는 구글의 초기 개발자가 로봇에 집중해 보겠다고 창업한 회사인데
회사의 창업 목적이 로봇 소프트웨어 표준을 만들겠다는 거였나 봅니다.
자체 로봇 하드웨어 플랫폼도 개발해서 ROS를 심고 발표한 건 좋은데
심각한 일은 2010년도에 벌어집니다.
이 회사가 (로봇 벤쳐로는) 엄청난 자본을 수혈받고
자신들의 로봇과 ROS를 세계 각국의 로봇 연구실에 확 뿌려버린 겁니다.
한국에서는 고만고만한 중소기업들이랑 국책연구소 몇 팀이 달라붙어서
열심히 깨작깨작 하고 있는데
미국넘들은 실리콘밸리의 위엄으로 융단폭격 형태를 취한 것 같이 느껴졌습니다.
아무튼 이후로 ROS가 점점 덩치를 불리더니
서구권의 여러 업체들이 ROS를 적용하고 결과를 보여주고 하면서
순식간에 주도권을 잡아버린거죠.
2010년도 접어들면서 우리나라 OPROS에서도 가만히 보고 있다가
2011년도 들어와서 기존의 계획을 대폭 보완하면서
ROS에 대항해 나가겠다고 하는 모양입니다.
============================================================
OPROS, ROS 등
이와 비슷한 다른 개발건들은....
일본의 RTM 이라는 과제가 있었는데,
우리나라처럼 정부지원 받아서 학계에서 하는 거였나 본데
진행과정이 아주 개판이라 성과가 별로 안좋았나 봅니다.
2009년인가 2010년인가 그때 쯤에 지원과제 종료되어 버리고
지원을 못받게 되자 소스코드 오픈해서 오픈소스화 합니다. (OpenRTM으로 전환)
이전에는 소스코드 비공개였는데 바꿀 수 밖에 없었던거죠.
이후에 개발이 잘 되고 있는지는 잘 모르겠지만
개발범위도 OPROS에 비해서 좁고 제한적이라 아마 거의 죽은 놈 취급해도 될 듯 하고요.
유럽에서는 OROCOS[오로코스?]라는 놈이 있는데
이놈도 독자적으로 하다가 윌로우 개라지의 ROS와 협력하는 쪽으로 방향을 잡았나 봅니다.
시스템은 ROS로 하고 그 위에 올라타는 알고리즘 같은걸 하는 쪽으로 방향을 잡은거죠.
ROS의 경우는 처음부터 BSD 라이센스로 오픈이었는데
OPROS도 그 영향 때문인지 2009년에 결단을 내려서 LGPL 라이센스로 완전 오픈했고요.
이외에도 다른 자질구레한 것들도 많던데
생략...
============================================================
아무튼 이런 성격의 소프트웨어 플랫폼들은
일반 OS 또는 RTOS 위에 올라타는 미들웨어 성격이 강하다고 할 수 있는데
ROS는 철저하게 리눅스 위주로 개발되었고
OPROS는 윈도우 개발자들이 많은 한국 현실(?)을 감안해서 윈도우 환경 위주로 주로 개발되었습니다.
하지만 그렇다고 다른 OS에 포팅되지 않은 건 당연히 아니고 다 크로스 되긴 했죠.
최근에는 안드로이드 OS 등이 나오면서 그쪽으로도 올라타는 모양입니다.
(ROS는 안드로이드 포팅 완료, OPROS는 아직 미구현이지만 몇 달 안에 된다고 함)
또
ROS는 하드웨어와 연결되는 디바이스 다루는 하부 구조 부분은 좀 약한 편인듯 하고
그보다 상위단의 알고리즘이나 각종 툴, 시뮬레이션 개발용 툴들에 집중하는 듯 하고
OPROS는 하부 구조 부분도 처음부터 상당히 중시하고,
또 개발환경(IDE)나 RAD 개념의 도구들도 개발범위에 들어가 있었습니다.
다만 OPROS는 알고리즘 부분이 좀 약한것 같아요.
거 왜 영상처리라던가, 네비게이션, 로봇 기구 모델링 및 실시간 동역학이라던가 등등 그런거요.
아무튼 OPROS는 이제 ROS를 철저하게 경쟁자로 인식하고
ROS의 장점들도 막 흡수하기로 맘을 먹었나봐요.
또 가능하다면 ROS 쪽과 협력을 추진하겠다는 계획도 있나본데
잘 성사가 될지는 아직 미지수...
이와 별도로 OPROS, ROS와는 좀 성격이 다른
MS의 MSRDS도 있쟎아요.
이넘은 하드웨어 구동 보다는 시뮬레이션 쪽에 비중이 큰 넘 같고
철저하게 닷넷 개발환경에만 맞춰져 있고 또 독점소프트웨어라는 점이 특징이죠.
MS 답게 커리큘럼이나 각종 라이브러리가 빵빵하고 해서
로보틱스 학습 교재로 미는 모양인데
다만 이걸로 로봇 제품을 개발하겠다는 경우는 못 본 것 같습니다.
============================================================
현재까지 보면
기술적 수준이 가장 높은 것은 단연 ROS 쪽인데
소프트웨어의 아키텍춰가 더 우월하다는 소리는 아니고
그걸 이용한 어플리케이션이 가장 수준이 높은 결과물들이 많이 나왔습니다.
세계적으로 돈을 뭉텅뭉텅 쓰면서 확 뿌리고
최고의 개발자들이 달라붙어서 하기 때문이겠죠.
OPROS는 이전의 RUPI 영향 때문에
로봇의 알고리즘 보다는
통신망을 활용한 서비스 개념이 강했기 때문에,
로보틱스 이론의 고급 알고리즘 부분은 굉장히 취약하지만
특이하게 서버-클라이언트 원격 제어 및 관리 개념이 초기부터 있었습니다.
이걸로 실제 구현도 하고 시범서비스도 하고 했었지요.
ROS는 무거운 우분투 리눅스 위에 올라타고 아키텍쳐가 덩치가 큰 편인지 몰라도
좀 반응이 느리고, 또 컴퓨팅 파워를 많이 소모하는데도 불구하고
서버-클라이언트 개념은 초기부터 가지고 있지 않았었던 것 같아요.
이제 와서 클라우드로 원격 서버에서 상위 알고리즘을 돌려서
로봇 클라이언트한테 지령을 줘서 동작을 하겠다는 둥 말을 하기 시작하더군요.
(참고로, 윌로우 개라지가 개발한 PR2라는 로봇의 경우
로봇의 모터의 소모전력은 170와트 미만인데, 내장된 컴퓨터의 소모전력은 500와트 정도라고 합니다.
상위 알고리즘 돌리는데 컴퓨팅 리소스가 엄청나게 필요한가 봅니다.)
아무튼 면면을 대략 살펴보면 일장일단이 있고
OPROS가 ROS의 결과물들에 비해서는 좀 쫄리는게 확실합니다만
그렇다고 내세울게 전혀 없는건 아니라는 것 같습니다.
개인적인 바램은 OPROS가 ROS와 서로 융합했으면 하는 생각도 듭니다.
============================================================
우리나라가 OPROS를 중요한 과제로 일찍부터 시작했던 것은 정말 잘한 일인 듯 싶습니다.
이제 구현도 어느정도 되었고 하니 2012년부터는 상당히 공격적으로 움직이면 좋겠습니다.
다른나라에도 막 뿌리고 말이죠...
다만 예산이 너무 적더군요.
연간 45억 정도 투입되는 것 같은데 (이중에 정부 지원자금은 80~90% 정도 되겠죠)
윌로우 개라지는 같은 금액을 그냥 한 번 로봇을 뿌리는데 쓰더군요.
2010년에 자사 로봇 11대를 세계 각국의 연구실에 그냥 공짜로 주고
그걸로 연구개발 속도 높이자 하는 기사가 떴었는데,
그 공짜로 뿌린 로봇 가격만 4백만불(약44억원) 이었으니까요.
(로봇 1대 가격이 대략 36만불 정도였다는 이야기이고
2011년 최신 버전의 PR2 로봇은 20만불 이라고 합니다.)
달리말해 미국의 일개 작은 벤쳐회사가 개발에 쓰는 돈보다
한국의 국책사업으로 한국 로봇업계가 다 달라붙어서 개발하는 돈이 훨씬 적다는 거죠.
아 뭐 이런건 당연한 거라고 해야겠지만...
우리는 미국이 아니니깐.
아무튼 개발에 투입되는 리소스가 부족하기 때문에
주도권 잡기 상당히 힘든 것은 분명합니다.
ROS 쪽과 협력하지 않으면 OPROS는 결국 갈라파고스화되어 고사하게 되겠지요...
============================================================
이러한 로봇의 소프트웨어 플랫폼을 개발해서 왜들 주도권을 잡으려고 할까?
나름대로 큰 시장이 열릴 것으로 기대되기 때문인 것은 확실합니다.
OPROS 과제 보고서를 보면
뭐 관련산업까지 합쳐서 '300조 시장' 이라고 좀 뻥을 쳐서 표현을 했던데
그정도까지는 안되더라도 큰 시장이 열리는 건 아무도 부인 안하는 것 같아요.
단적인 예를 들어볼 수 있는게....
산업용 로봇 시장이 포화상태에 접어들어
(주요 수요자인 자동차 생산라인이 과잉상태가 되었기 때문에)
상당기간 정체 상태였다고 합니다만
신흥경제권 쪽에서 신호가 오는 모양입니다.
애플 아이폰 조립해 주는 폭스콘의 경우
지난번에 열악한 노동환경으로 공장 종업원의 연쇄 자살 사건이 일어나
큰 파문이 일었는데
그 폭스콘의 혼하이 그룹 회장이
'생산라인에 50만대의 로봇을 투입해서 인간을 대체하겠다'
라는 위엄어린 선언(?)을 해 버리죠.
그냥 대륙의 뻥인가 싶었는데
이번에 보니, 이미 로봇 10만대 투입되어 있고
2013년까지 10만대 더 투입한답니다.
기존의 소형 제품 조립라인의 로봇들은 기껏해야 부분적으로 적용되는 수준이었는데
(사출물 취출, 나사 조임, 물류 팔렛트 이송 정도..)
로봇을 제대로 적용하기 위해서 FMS 개념 즉
원자재 창고 -> 생산라인 전부 -> 출고 창고 까지 모든 과정에 로봇을 깔아놓고
생산을 사실상 무인화한다는 겁니다.
기존의 미국 등에서 시도했던 무인화 공장들이 실패했던 원인은
원재료의 재고량을 극단적으로 줄여서 재고부담을 최소화 하겠다는 식의
탁상머리에서 나온 산업공학이 목표였기 때문이라고 할 수 있는데
FMS 개념은 그보다는 좀 달라서
공장에서 사용되는 지그(Jig) 등의 유연하지 못한 부속들을 없애고
로봇과 공구들 만으로 모든 작업을 해 낸다는 겁니다.
생산하는 아이템이 달라지면 소프트웨어만 손보고요.
산업공학적인 목표가 수정되고, 더 새로운 개념이 시도되는 시점이기 때문에
산업용 로봇 수요가 다시 증가곡선을 타고 있습니다.
그 외에도 뭐 군사용 로봇이라던가
(아프간 전쟁에 아이로봇 제품이 연간 5천대 가량 투입되었다고 하네요)
로봇의 제어/지능이 가까운 미래에 더 향상되고
로봇 가격이 절감되는 시점에 등장할 범용 서비스 로봇 시장이 발생한다면
할만한 사업이 되는 거죠.
이런 모든 로봇의 기반 소프트웨어 플랫폼이
마치 PC의 윈도우즈 처럼 쫙 깔린다고 생각하면 엄청난 사업이 되는 거겠죠.
============================================================
현재 우리나라 소프트웨어 개발자들중 대다수는
서버, 웹개발 쪽인 것 같고
어플리케이션 개발자가 좀 있고
SI 쪽은 뭐 막장 개념이라고들 하고요..
로봇 쪽에 관심이 있다면 이런 동향에 촉각을 곤두세워 보는 것도 어떨까 싶습니다.
제가 로봇 개발 업체에서 일해본 바로는
함께 일하던 개발자들이 아직 Guru나 고수급은 별로 없습니다.
컴퓨터 공학을 제대로 공부한 인력도 적은 편이고요.
대부분 전자공학,기계공학 전공자 출신들이 하는 경우가 많죠.
아무래도 컴퓨터공학적인 깊이가 좀 떨어질 수 밖에 없는 것 같습니다.
실력이 뛰어난 개발자가 로봇 쪽에도 좀 더 투신하기를 바라는 마음에서 써 본 글입니다.
사실 대우는 뭐 .... ㅎㅎㅎ
현대중공업 말고는 대우 좋은 곳은 없다고 보셔도 될 듯..
아 뭐 그래도 꿈과 희망이 아직은 남아있는 분야 아닌가 해요.
* 참고할 만한 곳
한국 OPROS ::: http://www.opros.or.kr
미국 ROS ::: http://www.ros.org
미국 Willow Garage ::: http://www.willowgarage.com
유럽 OROCOS ::: http://www.orocos.org
일본 OpenRTM ::: http://www.openrtm.org
MSRDS ::: http://msdn.microsoft.com
재밌는 글 잘읽었습니다. 여러가지 생각이 들게
재밌는 글 잘읽었습니다.
여러가지 생각이 들게 만드는 스토리네요.
Just do it!
OPROS에는
Willow Garage의 PR2 처럼 판매가능한 견고한 로봇 플랫폼이 있나요?
OPROS를 잘 알진 못하지만 소프트웨어 개발 스택인 것 같은데, 사실 회사도 아니고 대학들이 PR2를 원한 이유는 통합 소프트웨어 플랫폼은 아니었습니다. 견고한 손이 달린 움직이는 로봇이 필요했죠. 이게 대학 연구실이나 일반 랩에서는 쓸만한걸 만들기가 힘드니까요. Tooling 은... 저라면 아마 거의 없는 걸 더 원했을 지도 모르겠습니다. 원하는 대로 소프트웨어를 짜는데 종종 방해가 되니까요.
PR2가 사실 갑자기 튀어나온 녀석도 아닙니다. 스탠포드에서 만들던 PR1 의 확장판이죠. PR1이 2006년부터인가 만들어졌고 ROS도 그때 만들던 것을 Willow Garage에서 이어받은 걸로 알고 있습니다. MIT 나 Stanford 등에서 팔달린 로봇을 1960년대 후반부터 만들기 시작했던 걸 생각하면 노하우는 충분한 셈이죠. 단지 대학원생들이나 스타트업에서 만들다 보니 tooling에 신경을 안썼을 뿐이라고 봐야겠습니다.
지금 이걸로 재미난 일들을 많이 하고 있는데, Berkeley에서는 빨래를 개고 있고
http://www.youtube.com/watch?v=Thpjk69h9P8
MIT 에서는 빵을 굽고 있습니다
http://www.youtube.com/watch?v=duXFIKswTOM
빨래 개는 일의 경우 정해진 시퀀스로 개는 건 아니고, 빨래가 접힌 경우 어디를 집어야 옷감이 펼쳐지는지 등을 확률적 모델링으로 추론합니다. 중간에 빨래를 돌려가면서 모양을 파악한 다음 어디를 집어야 하는지를 계산하기도 하구요.
Berkeley 동영상의 저 대머리 젊은 교수 Pieter Abbeel 세미나에서 기억에 남는 말중 하나가, 자신이 로봇으로 빨래 개는 일에 관심을 두는 이유는, PR2가 현재 나온게 2억짜리인데, 이게 대중화되어 여러 분야에 쓰이기로는 너무 비싸다, 그래서 자신과 같은 사람들이 로봇으로 이런 everyday task도 할 수 있다는 것을 보여주면 예를들면 foxconn 을 설득해서 한대당 500만원짜리를 찍어내도록 할 수도 있지 않겠느냐, 고 하더군요. 저는 연구를 할때 이런 적으로 생각해본적이 별로 없어서, 얘네는 생각의 스케일이 다르구나를 느낄 수 있었습니다.
그렇군요 진짜 스케일이 다르네요 멋집니다. 역쉬
그렇군요 진짜 스케일이 다르네요 멋집니다.
역쉬 로봇 개발(초기 접근)에 제일 걸림돌은
하드웨어 실제 플랫폼인거같네요
인생은 도박이다.
3PO나 R2D2같은것도 나오겠군요
3PO나 R2D2같은것도 나오겠군요
피할 수 있을때 즐겨라! http://melotopia.net/b
좋은 정보 글 감사합니다. 관심은 많지만 아직
좋은 정보 글 감사합니다.
관심은 많지만 아직 접해보지 못한 이야기네요
간간히 이런글 올려주시면 감사하겠습니다.
인생은 도박이다.
오~ 재미있습니다.
좋은 글 잘 읽었습니다 ^^
Robotics는 Rigid Body
Robotics는 Rigid Body Dynamics에서 끝납니다.
길게 쓰셨는데...
4발로 걷는 로봇은 이미 실용화 단계에 있습니다. 미국 국방부에서 개발중입니다.
두발로 걷는 로봇은 혼다가 가장 앞서 있는데 2020년에는 사람 축구 선수와 시합을 해서 이길정도로 만들거라고 했는데 지켜봐야 지요.
사람의 몸이 만드는 모든 동작을 위치와 시간의 미분 방정식으로 구현하면 진짜 사람같이 움직이는 로봇을 만들 수가 있는 거지요.
3차원 게임들에 사용하는 물리 엔진 (Physics engine)은 중학교 물리 교과서 공식 베껴다 쓰는 수준이고, 오차와 다루는 변수들이 많을 수록 캐드, 전문 시뮬레이션 프로그램이 됩니다.
진자가 두개가 되면 비선형으로 움직입니다. 여기서 부터 Chaos가 시작된다고도 하더군요. 물리학책에 써있습니다. 사람의 팔은 두개의 진자, 손은 4개의 진자로 이루어져 있지요. 여기에 팔은 회전, 어깨는 360도로 회전하니, 이 시스템이 만들 수 있는 상태를 나타내는 운동 미분 방정식을 찾기가 어렵습니다.
Devuan 1.0 (Debian without systemd)
amd64 station: AMD FX(tm)-6100 Six-Core Processor, 8 GB memory, 1 TB HDD
amd64 laptop: HP Touchsmart
글쇠판: 세벌 최종식, 콜맥 (Colemak)
이 글을 보고 나니 이 뉴스가 눈에
이 글을 보고 나니 이 뉴스가 눈에 띄네요.
http://www.pointclouds.org/news/urban-robotics-extends-octree-format-to-pcl-open-source-community.html
http://www.pointclouds.org/news/kinectfusion-open-source.html
* 포럼 주제와 무관한 신변잡기를 반복해서 올리지 맙시다.
* 질문 게시판 만이라도 익명 글쓰기를 막아야 한다고 생각합니다.
재밌는이야기
재밌는 이야기 잘 읽고 갑니다 ^^
정말 잘 읽었습니다.
정말 잘 읽었습니다.
잘 읽었습니다.
로봇 소프트웨어 쪽으로 전공을 하고 있는 저와 관심 분야가 매우 비슷한 것 같습니다.
개인적으로 말씀을 더 나누고 싶은데, 혹시 이메일 연락처 하나 알 수 있을까요?
제 이메일은....
저의 닉네임에 naver.com 으로 보내주시면 됩니다.
저도 로봇 학계나 업계에서 무슨 대단한 입지를 가진 사람은 아니기 때문에
깊숙한 정보까지는 알지 못하지만, 혹시 도움이 될만한 사항이 있다면 언제든지 연락 주십시오.
감사합니다.
======================================
Mechanical Engineer
DymaxionKim.github.io
======================================
로봇쪽 SW에 투신하려거든...
요 몇년간 로봇쪽 SW 플랫폼 개발에 참여했던 한 사람으로서 짧게 댓글 남깁니다.
로봇쪽 연구&개발인력들은 대부분 기계,전자,제어쪽 인력으로 SW에 대한 이해도가 상당히 낮은편입니다. 따라서 어느 정도 실력만 있으면 일정부분 기여할 수 있습니다만... SW에 대해 함께 논의할만한 동료가 거의 없고, SW 결과물을 거의 인정해주지 않기 때문에 조직내에서 인정 받기가 쉽지 않습니다. 로봇하는 사람들 대부분이 워낙 눈에 보이는 것만 좋아하기 때문에(단적인 예로 로봇쪽 논문에서는 동영상이 거의 필수라고 하더군요) SW는 인정받기가 정말 힘듭니다.
혹시 그쪽으로 진출하고자 하시는 분은 이런 점도 고려하시면 좋을 것 같습니다.
설명드리자면
로봇쪽 논문에서는 동영상이 거의 필수라고 하셨는데 동영상은 결국 개발한 알고리즘의 테스트 결과를 의미합니다. 시뮬레이션 결과지요.
거의 필수가 아니라 그냥 필수입니다. 이것이 없이 어떻게 검증을 하겠습니다.
요즘은 시뮬레이션뿐만 아니라 실제 하드웨어 테스트가 거의 필수가 돼 버렸습니다.
하드웨어 기술은 어느 정도 수준에 올라왔습니다. 로봇 청소기 같은 것이 일반 가정에 꽤 보급된 것을 보면 알 수 있지요.
이 말인 즉슨 소프트웨어적으로 개발한 알고리즘의 실제 성능을 테스트하기 위한 하드웨어를 마련하기가 손쉬워졌다는 것이죠.
이상적인 환경의 시뮬레이션보다 실제적인 하드웨어 테스트로 검증한 것이 더욱 설득력있는 것은 당연합니다.
SW로 인정받기 힘들다고 하셨는데 어떤 부분을 말씀하시는지는 잘 모르겠지만
단순 개발로는 인정받기 어려운 것이 당연합니다. 이미 말씀드린 것처럼 '구현'은 하나의 도구에 지나지 않기 때문이지요.
참여한 플랫폼의 독특한 특성을 반영한 새로운 디자인 구조나 아키텍쳐를 설계하여 개발하는 수준이 아니라면 말이지요.
research가 아니라 skill의 영역으로 바라보는 성향이 있기 때문에 그렇습니다.
간만에 보는 정말 멋진 서베이 글이군요! 고맙습니다.
간만에 보는 정말 멋진 서베이 글이군요! 고맙습니다. ;-)
@dymaxion++
----
use perl;
Keedi Kim
좋은 글 잘 읽었습니다. 그동안 막연하게 로봇
좋은 글 잘 읽었습니다.
그동안 막연하게 로봇 플렛폼에 대한 개발을 생각하고 있다가,
최근에 회사일 하고 남는(?)시간을 어떻게 활용할까 하다 알아보던중 이 글이 검색되었습니다.
감사합니다.
----------------------------------------------------------=>
Be supercalifragilisticexpialidocious, run for your life!
국내에서 진행된 과제와 사업들에 대해 애정어린 시선을
국내에서 진행된 과제와 사업들에 대해 애정어린 시선을 가지고 계신 것 같습니다만
제 개인적으로는 오히려 그 반대입니다.
ROS와 OPROS의 성능에 대해 평가해 주신 부분에 대해서도 역시 동의하기는 어렵습니다.
먼저 말씀하신바대로 공통의 로봇 개발 환경을 개발하고자 하는 움직임은 20세기 후반에 태동했습니다.
대표적으로 언급하신 OROCOS 는 유럽을 중심으로, 일본에서는 HRP 로봇을 개발하기 위한 소프트웨어 환경으로 OpenHRP 가 있었습니다.
당시는 로봇 하드웨어 플랫폼과 컴퓨팅 파워, 각종 센서 등 실제로 활용할 만한 환경이 갖춰져 있진 않았기 때문에
지역적으로만 활용될 뿐이었습니다.
로봇 소프트웨어 플랫폼의 중요성이 대두된 중요한 계기 중 하나는 모바일 로봇에서 보행 로봇으로의 연구 플랫폼의 변화였습니다.
로봇의 동역학 해석이 중요해졌고 아담스와 같은 기존의 전통적인 동역학 해석 프로그램 들은 로봇의 운동을 시뮬레이션 하기에는
무겁고 오래걸렸습니다. 그렇다고 동역학 시뮬레이션 프로그램을 직접 작성하자니 이건 완전 배보다 배꼽이 더 커지는 경우가 되고요.
그래서 3차원 동역학 시뮬레이션 하다 못해 기구학 시뮬레이션이 되는 개발 환경에 대한 요구가 증대되고 있었습니다.
1998년 Russell Smith의 Open Dynamics Engine(ODE)이 세상에 나오고 그 이후 로봇 동역학 시뮬레이션은 이 엔진을 이용하게 됩니다.
오픈 소스이므로 이 엔진을 이용한 상용 소프트웨어도 여럿 발표됩니다. (Webots 등)
강체 동역학 계산은 이미 성숙한 분야로 수학적으로는 완성되었으나 프로그램으로 잘 짜여진, 그리고 널리 사용된 놈은 ODE가 사실상 최초였습니다.
(동역학 시뮬레이션 엔진 기술에 관련해서는 국내에도 simlab 이라는 좋은 회사가 있습니다. 이 회사도 초기에는 ODE 엔진을 활용했지만 지금은 자체
엔진을 가지고 있습니다. 또한 서울대학교에도 동역학 시뮬레이션 엔진이 있습니다.)
이 즈음에 또다른 중요한 오픈소스 라이브러리가 만들어집니다. USC의 Brian Gerkey가 Player 라는 로봇 서버 프로그램을 만듭니다.
이후에 Player/Stage/Gazebo 로 확장되고 종국에는 Willow Garage에서 ROS로 재탄생됩니다. Player는 로봇을 구성하는 하드웨어 및 소프트웨어 컴포넌트들 간의 데이터를
손쉽게 주고 받을 수 있도록 해주는 일종의 미들웨어 역할을 하고 Stage는 2D 기구학 시뮬레이션, Gazebo는 ODE를 통해 3D 시뮬레이션을 할 수 있도록
인터페이스를 해줍니다. Player의 개발자가 Brian Gerkey, Gazebo의 개발자가 Nate Koenig 입니다. 현재 ROS의 개발 및 배포를 맡고 있는
OSRF의 창립멤버 들이죠.
Brian Gerkey는 2003년 박사학위를 받은 이후에 Stanford, SRI 등을 거치면서 로봇 커뮤니티에 Player/Stage/Gazebo를 확산시키기 위해 많은 노력을 했습니다.
실제로 모바일로봇 플랫폼에서는 꽤 널리 사용되기도 했습니다. 그러던 중 2008년에 Willow Garage에 합류하면서 ROS를 개발합니다.
그 이후에 ROS 개발의 핵심인력들이 빠져나와 OSRF를 만듭니다. OSRF는 현재 ROS 2.0 버전 개발에 착수했고
Willow Garage는 한 두달 내로 문을 닫을 거라는 공식적인(?) 소문이 돌고 있습니다.
아무튼 ROS는 어느날 뜬금없이 나타난 놈도, 거대 자본의 돈을 발라 만든 놈도 아닙니다.
원류를 따져보자면 이미 10년도 훨씬 넘은, 대학의 한 연구실에서 탄생한 놈입니다.
아무튼, 2000년대 중반에 로봇 커뮤니티에서 실시간 동역학 시뮬레이션 기능을 갖춘 로봇 소프트웨어 개발 환경에 대한 관심이 고조되고 있었습니다.
특히 마이크로소프트사에서 야심차게 Robotics Develop Studio를 내놓은 것이 큰 반향을 불러일으켰습니다.
(저는 RUPI에 대해서는 잘 모릅니다만) 국내에서는 Robotics Develop Studio에 대항할만한 개발 환경을 우리도 만들어야겠다 하여 과제를 공모하고
선정된 것이 현재 OPROS라고 불리는 차세대 로봇 소프트웨어 플랫폼 과제가 런칭됩니다.
(아래는 개인적인 의견과 정확하지 않은 정보를 포함하고 있습니다.)
의도는 거창했을지 모르지만 그것은 나중에 덧칠해진 것이고 전형적인 국가 예산 나눠먹기 사업이라고 봅니다. 특히 잘못됐다고 생각하는 점은
과제 총괄책임자 분이 로봇과는 거리가 있는, 소프트웨어 아키텍쳐/통신 관련 전공자 분이시라는 겁니다.
과제 초반 OPROS를 관통하는 키워드는 유비쿼터스였습니다. 당시 유행하던 단어이기도 했지요. 그래서 컴포넌트만 연결하면 언제 어디서나 컴포넌트를 실행하여
뭔가 할 수 있다... 뭐 이런 식이었지요. 정말 필요한 기능에 집중하기 보다는 예산에 맞춰 기능을 늘리다보니 지나치게 무겁고 덩치가 커진게 아닌가 싶습니다.
어찌됐건 제가 드리고자 하는 말씀은,
2009년에 시기가 적절하게 맞아 떨어지고 Willow Garage가 큰 투자를 받으면서 그 영향력이 크게 상승한 것은 맞습니다만 ROS는 갑자기 나타난 복병도 아니고 엄청난 자금을 들여서 만들어진 놈도 아닙니다. 이미 ROS의 전신인 Player로의 흐름은 2000년대 중반부터 존재했습니다. 오히려 OPROS가 제대로 된 사전 준비도 없이
어느날 갑자기 나타나서 엄청난 국가예산을 받아 진행된 사업이지요.
로봇 관련 소프트웨어와 관련해서는 리눅스 기반
로봇 관련 소프트웨어와 관련해서는 리눅스 기반 오픈소스가 전세계적인 대세입니다.
로봇 소프트웨어 관련해서 미국과 유럽이 주도권을 가지고 있는데 연구자들의 공통적인 마인드가 free software/open source 입니다.
그래서 마이크로소프트가 MSRS를 런칭했을 때 유럽 학계에서는 엄청 비난을 했지요.
미국이나 유럽의 대학이나 학회에 가보면 유닉스 계열(리눅스, 맥) OS가 다수입니다.
가볍고 잘 돌아가고 소스가 공개된 소프트웨어가 장땡입니다. 잘 돌아간다는 것은 결국 잘 만들어졌다는 것이죠.
오픈 소스가 좋은 점이 전세계의 날고 뛰는 뛰어난 소프트웨어 개발자들이 거리낌없이 참여하여 기여할 수 있다는 점입니다.
따라서 유용하다면 영속성을 갖게 끊임없이 개선돼 나갑니다.
많은 기능 제공한다고 필요없이 무겁거나 윈도우즈에서만 돌아가는 소프트웨어는 환영받지 못합니다. 과제 종료와 동시에 관리로 종료되는
소프트웨어는 없느니만 못하게 됩니다.
그래서 제가 OPROS의 미래는 없다고 보는 것이고 과제 자체가 잘못된 방향으로 향하고 있다고 보는 것입니다.
과연 과제 책임자분들중에 로봇관련 소프트웨어를 직접 개발해 보신 분들이 얼마나 되실지 궁금합니다.
로봇 소프트웨어 개발과 관련해서는,
미국이나 유럽은 robotics 관련 연구실들이 대체로 컴퓨터공학과 소속입니다. 그에 반해 우리나라나 일본같은 경우는 기계공학과에 속해있지요.
위에서 언급한 Russell Smith나 Brian Gerkey도 모두 컴퓨터 공학과 출신들입니다. 그래서 동역학이나 제어 등의 학문적 깊이는 깊지 않지만
대신 소프트웨어 관련 지식이 깊어서 좋은 성과를 많이 냅니다. 현대의 로봇관련 연구는 사실상 알고리즘의 구현이란 측면이 강합니다.
특히 로봇에게 기대하는 autonomous behavior와 관련해서는 알고리즘이 다라고 할 수 있지요. 하드웨어는 이런 알고리즘들의 성능을 실증하기 위한
도구 정도이죠. 물론 개선된 또는 기발한 하드웨어의 개발 또한 중요합니다만 하드웨어 연구의 경우 인력과 자금이 집중되고 연구의 대상 및 방향을 쉽게 바꾸기 어렵습니다.
(말하자면 10억 들여서 휴머노이드 만들어 놓고 비젼 관련 연구할 수는 없지요.)
반면 알고리즘 관련 연구를 하는 경우는 최신 트렌드에 맞게 혹은 트렌드를 이끌면서 연구를 해나갈 수 있습니다. 사람과 컴퓨터만 있으면 되니까요.
국내는 여전히 하드웨어 백그라운드 성향이 강한것 같습니다. 이런 현상은 사실 좀 당연한 게 업체인 경우 하드웨어를 판매하지 않으면 이익이 발생하지 않기 때문이지요.
즉 소프트웨어만 해서는 펀딩을 받거나 수익을 창출하기가 쉽지 않습니다.
로봇 소프트웨어 개발 관련해서 진로를 생각하신다면 수학과 전산학을 공부하시라고 제안하고 싶습니다. 결국 프로그래밍은 도구일 뿐입니다.
정작 중요한 것은 프로그래밍을 통해 구현되는 기능에 있습니다. 이런 것들은 수학적 배경이 있을 때 강력해집니다.
어떤 언어를 공부하고 어떤 코딩 기술을 익히느냐는 닥치면 하게 됩니다.
뛰어난 개발자가 로봇에 관련해서 종사하느냐는 두번째 문제입니다. 그것보다 로봇 소프트웨어의 high-level(사용자 인터랙션)에서 low-level(하드웨어 컨트롤)까지
이해하고 전체를 조망할 수 있는 인재를 키우는 것이 중요합니다.
로봇은 그 자체로 이미 융합의 학문입니다. 하나만 파기 보다는 2~3가지 분야의 깊은 경험과 지식, 그리고 다양한 경험이 더욱 도움이 될 것입니다.
(예를 들어 비전과 기계학습에 대해 잘 알고 경험이 있으면서 디자인이나 심리학에 흥미가 있어서 책을 좀 읽었다.)
제가 판단하기에 로봇 하드웨어 및 소프트웨어 개발에 관련된 인프라는 이미 잘 갖춰졌다고 생각합니다. 간단한 로봇을 구성하기 위한 각종 장치들의 가격도 상당히 낮아졌고
손쉽게 프로그램을 구현할 수 있는 환경도 잘 갖춰져 있습니다. 그리고 로봇관련한 다양한 연구들이 수행되어 당장 상업화 가능한 수준의 완성도를 보여주는 것들도 많이 있습니다.
즉, 요리를 하기 위한 식재료와 도구들이 어느 정도 갖춰져 있는 셈입니다. 이제 관건은 이것으로 '어떤' 요리를 만들것인가 하는 것입니다.
이것은 한가지만 판 사람으로부터는 기대할 수 없습니다. 학문뿐만아니라 사회에서의 다양한 경험과 이를 바탕으로 한 아이디어가 절실히 요구되는 시점이 되지 않았나 생각합니다.
성의있는 덧글 감사드립니다~
본문 글에서 미처 말하지 못했거나,
또는 부정확한 부분들을 잘 보충해 주신 덧글 같아서
정말 감사드립니다.
정부지원과제라는게 아무래도 좀 그런 속성이 많죠 ㅠㅠ;
비효율적인 부분이 분명 많긴 하지만
어찌보면 그게 나름대로 기회요소가 될 지도 모른다고 생각을 해 봅니다.
좀 나이브한 생각이긴 하지만,
로봇 쪽은 아직 미개척이거나 미성숙된 기술들이 많기 때문에
엔지니어로서의 야심을 가진 사람이라면
투신해서 업적을 남길 만한 꺼리(?)가 그만큼 널러있다고도 생각하니까요.
OPROS과제에 대해서는,
제가 만나본 몇몇 실제 개발에 참여한 개발자들의 의견도 대체로
부정적인 편이더군요...
하다못해 홈페이지 관리도 제대로 안되는 판이니.
하지만 이 프로젝트에 참여한 수많은 젊은 개발자들은 이런 기회를 통해
나름의 경험과 지식을 축적했을 거라고 생각합니다.
로봇의 제어 관련한 이론은 지금도 계속 한참 발전하는 중이고
전통적인 Inverse Kinematics 솔루션들도 최근에는
다양하고 점점 더 퍼포먼스가 좋아지는 Pseudo Inverse
또 더 최신 방법으로는 Partial Pseudo Inverse 방법도 나오는 등
실시간 연산속도를 대폭 끌어올리면서도 실용적으로 사용하기 좋은 방법들이
계속 발전해 가고 있는 것 같습니다.
또 최근에는 Linear Algebra 기반의 전통적인 해석 방법과 다른
Lie Algebra 기반으로 해석하는 현대수학적 기법들도 학계에서 다루어지고 있는 모양인데
이렇게 현대수학 영역으로 넘어오니, 저도 이해할 수 없는 안드로메다(?)가 되어가고.. ㅠㅠ;
수학공부 잘하는 소프트웨어 엔지니어라면 정말 최적합하겠구나 싶어요.
======================================
Mechanical Engineer
DymaxionKim.github.io
======================================
.
.
로보틱스 이론의 고급 알고리즘 부분이 중요하죠
서버-클라이언트 원격 제어 및 관리 개념 따위는 과제 따먹기에 주로 쓰이는 단골 아이템이죠
언제든 갖다 붙일 수 있는 기술들입니다...
로보틱스에 기계 전공자들이 붙든 S/W 공학자가 붙든 그런건 아무래도 상관이 없습니다.
어차피 둘다 알아야 하는 거거든요
일반 기계 전공자들이 프로그래밍을 어려워 하듯
S/W 공학자가 로봇 제어 하기도 어렵습니다...
굳이 더 비교하자면 S/W 공학자가 더 유리한게 정상적이기는 한데...
국내 현실상 대학이나 현업 프로그래머들을 봐도 수학/물리학의 이해도가 높은지는 의문입니다.
뭐랄까 수학적 이론 보다는 프로그래밍 테크닉에 더 크게 의존한다는 느낌입니다.
기초 역학과 물리학적 개념은 잡고 들어가야 하는데.... 이부분에서 우리나라 경우엔 갭이 커 보입니다.
차라리 기계/물리 전공자중 프로그래밍을 하는 분들이 맡는게 나아보입니다.
프로그래밍을 독학하긴 쉽지만 기계,물리를 독학하기는 좀 어렵기도 하고요....
뭐 이건 개인적이고도 편협한 견해일 뿐입니다.
그럼에도 국내에 성공사례가 있긴 합니다.
국내 기술벤쳐회사중에 functionBay라는 회사가 있는데
기계공학 해석 소프트웨어인 Recurdyn[리커다인] 이라는 제품으로 유명한 회사입니다.
미국에서 DADS[댓즈]라는 동역학 해석 소프트웨어 개발에 참여한 경험을 가진 박사님이
국내에서 대학교수로 재직하면서, 랩실에서 초기버전 개발을 시작했고
그걸 사업화하여 성공적으로 시장에 진입하였는데요.
동역학 해석하는 이론을, 전산전공 개발자들이 확실히 알고 들어가기는 힘들지만
잘 아시다시피 사실 이런 종류의 핵심 이론 자체는 매우 간결하기 때문에
원리를 이해만 한다면 그걸 알고리즘으로 구현하고 제대로 동작이 되도록 만드는 게
요원한 일만은 아니라고 생각이 들더라고요.
======================================
Mechanical Engineer
DymaxionKim.github.io
======================================
로봇 SW인 OPRoS에 대한 실제와 오해
OPRoS 과제 총괄하시는 분은 제어/자동화/실시간시스템 관련되어 깊이 연구하신 분입니다. 아마 논문도 이와 관련된 내용이 많은 것으로 생각됩니다. OPRoS는 처음부터 유비쿼터스 개념을 가지고 출발하지 않은 것으로 생각합니다. 잘모르신다는 RUPI가 유비쿼터스 개념을 가지고 출발한 것으로 생각됩니다.
ROS는 unknowny 님께서 말씀하신 바와 같이 오랜 시간동안 만들어져서 10대의 PR2를 세계에 무료로 배포하여 여러 성공적인 사례를 만들었습니다. 실제로 다양한 연구기관과 업체에서 활용하고 있습니다. 앞으로도 계속 활용할 것으로 생각되어 집니다. ROS는 2007년에 초기 버전이 발표되었습니다. 그 후 2010년에 버전 1.0 ROS와 PR2를 발표합니다. 동시에 아주 비싼 PR2를 세계적인 유명 대학 및 기관에 10대를 배포하게 되며, 이 이벤트가 ROS를 성공적으로 만들게 됩니다. 그러나 장점이자 단점인 것은 LINUX를 활용한다는 것입니다. 다른 OS를 활용하는 것은 약간의 문제가 있습니다. 특히 국내에서는 LINUX보다는 윈도우즈가 많다는 것입니다. 또 다른 단점은 실시간을 지원하지 않는다는 것이고 이에 따라 실시간은 OROCOS 활용을 추천합니다.
OPRoS는 로봇 SW 개발에 필요한 것들(미들웨어, 개발도구, 테스트 도구 등)을 만들고 동시에 지금 현재 유행하고 있는 앱스토어를 지향하고자 만든 과제입니다. OPRoS는 ROS와 같은 미들웨어가 아니고 솔루션입니다. 즉, 로봇 SW 모듈을 개발하고 시험하고, 개발된 SW 모듈들이 통합하여 잘 동작하는지를 시뮬레이션을 통하여 검증한 후에 실제 로봇에 다운로드하여 검증할 수 있게하는 솔루션입니다. 이러한 형태로 개발하게 만든 것은 OPRoS가 세계에서 유일하며, 현재 ROS를 포함한 모든 기관에서는 이러한 형태를 개발하고자 하고 있는 것으로 알고 있습니다.
OPRoS 과제는 1년을 기획하여 IT 추세를 감안하여 향 후 로봇 SW가 가야할 방향을 예측하여 만들어진 과제이지 MSRDS를 타겟으로 만들어진 과제가 아닌 것으로 알고 있습니다.
그리고 말씀드리고자 하는 것은 국내와 외국에서 open source를 대하는 환경입니다. 노골적으로 말씀드리자면, 국내의 기술을 인정하지 않는 분들이 많다는 것이고 또한 국내에서 개발된 기술을 open하지 않는다는 것입니다. 이에 따라 국내 개발 기술이 나아갈 방향이 좁아지고 있는 것이지요. 사실 OPRoS 도 현재 이 분위기에 휩싸여 있다고 생각됩니다. 외국에서는 OPRoS 기술자체를 인정하는 분위기가 있다는 것을 말씀드리고자 합니다. 사실 장점도 많습니다. 물론 단점도 당연히 있지요.
먼저 OPRoS의 장점을 말씀드리면,
- OPRoS는 컴포넌트를 기관에서 개발된 것을 실행 파일로 판매 가능하다는 것으로 생각됨
(ROS는 현재 상태로는 불가능한 것으로 생각됩니다.)
- OPRoS는 도구를 활용하여 개발에서 검증까지 가능함
- OPRoS는 컴포넌트의 표준 인터페이스만을 지키라고 하지, 미들웨어를 그대로 사용하라고 하지 않음.
이에 따라 미들웨어는 다양한 기관에서 개발되어 동작하고 있음.
약간의 지식만 있다면 미들웨어를 고칠 수 있을 만큼 단순함.
(그러나 ROS는 미들웨어를 고치는 것은 불가능함)
- 미들웨어가 단순하기 때문에 다양한 운영체제(실시간 OS 포함)에 쉽게 올라갈 수 있음
OPRoS의 단점을 말하자면
- 많은 다양한 로봇에 대해 구현을 하지 못하였음. (이를 위해 도와주셔야 함)
- 다양한 컴포넌트가 없음. OPRoS도 다양한 컴포넌트를 여러분 개발자가 도와주면 빠른 시간내에 돈도 벌면서
많이 활용될 것으로 생각됨. (ROS의 경우는 다양한 SW 모듈이 존재하며, 로봇 개발자는 이러한 모듈들을 사용하기 위해서
ROS를 활용함. 특히 ROS의 경우는 같은 내용이라도 다른 동작을 하는 SW 모듈이 많기 때문에 안정적인 SW를 찾는 것이
현재 당면 문제임) 이에 따라 OPRoS는 그러한 문제는 없을 것으로 생각됨
- 현재까지 많은 예제가 없음
수정할 것 하나
다들 유익한 정보 감사합니다.
위의 unknowny 님과 robotSW 님의 답글에서 제 생각에는 unknowny님의 의견이 보다 올바른 것 같습니다.
1. unknowny님 의견: 과제 총괄책임자 분이 로봇과는 거리가 있는, 소프트웨어 아키텍쳐/통신 관련 전공자 분이시라는 겁니다.
2. robotSW님 의견: OPRoS 과제 총괄하시는 분은 제어/자동화/실시간시스템 관련되어 깊이 연구하신 분입니다. 아마 논문도 이와 관련된 내용이 많은 것으로 생각됩니다.
아래의 IEEExplore의 검색 결과와 DBLP의 검색 결과를 보면, 제어 분야의 대가이신 권욱현 교수님과 공저인 논문이 있지만 (물론 제어이론의 수학이 들어갈 수 있겠만) 대부분 주제은 통신입니다. 2009년 이후 OPRoS (로봇 소프트웨어 플랫폼) 논문이 있지만, 이들 또한 로봇 분야의 주요 학회(ICRA, IROS, RSS)의 논문은 아니고, acceptance가 매우(!) 높은 minor 학회의 논문이 대부분입니다. OPRoS 외의 로봇 분야 관련 논문(예: 인지, 학습, 계획, 제어, 주행, 조작 등등)도 별로 없는 것 같습니다.
- IEEExplore 검색: http://ieeexplore.ieee.org/search/searchresult.jsp?searchWithin%3Dp_Authors%3A.QT.Hong+Seong+Park.QT.&sortType=desc_p_Publication_Year&pageNumber=1&resultAction=SORT
- DBLP: http://www.informatik.uni-trier.de/~ley/pers/hd/p/Park:Hong_Seong.html
또 저뿐만 아니라 자동으로 논문의 저자를 분석하는 ArnetMiner에 "자동으로" 추출한 연구 주제도 모두 통신입니다.
- ArnetMiner: http://arnetminer.org/person/hong-seong-park-930360.html
로봇 플랫폼과 관련된 요구사항
^^.
일부분을 사용하여 일반화할 때는 매우 심도있는 분석이 필요하다고 생각합니다. 논문 관련 데이터는 틀린 것은 아니지만 일반화까지는 아닌 것 같습니다.
OPRoS나 ROS는 로봇에 활용하는 SW들(인지, 학습, 계획, 제어, 주행, 조작 등)을 잘 활용하도록 하는 미들웨어입니다.
따라서 이 미들웨어를 잘 동작하기 위해서는 다음과 같은 것들이 요구 조건들을 만족해야 합니다.
- 통신 (다중 보드들간 및 하나의 보드 내의 SW 들간 데이터의 송수신) : 실시간 통신, 비실시간 통신, 클라이언트/서버 통신, publish/subscribe 통신 등이 지원되어야 합니다.
- 스케쥴링 : 실시간 스케쥴링(우선순위, 멀티큐,EDF 등), 라운드로빈 스케쥴링
일반적으로 통신 부분만을 연동시켜 만든 것이 통신 미들웨어라고 하며
이 통신 미들웨어에 스케쥴링 기능을 추가시킨 것이 플랫폼입니다. 즉 미들웨어는 로봇에 실제 사용되는 SW와는 관계없습니다.
ROS는 비실시간 통신을 기반으로 클라이언트/서버 통신, publish/subscribe 통신을 지원하면서 일반적인 운영체제의 기능을 활용하도록 만든 프레임워크입니다.
OPRoS는 실시간/비실시간 통신을 지원하면서 클라이언트/서버 통신, publish/subscribe 통신(최근에 지원)을 지원하면서 실시간 스케쥴링을 가능하도록 하는 프레임워크입니다.
따라서 이 2개의 미들웨어를 연구하는 사람들은 대부분이 통신 부분과 스케쥴링을 하는 연구자들입니다. 따라서 unknowny께서도 말씀하였듯이 컴퓨터 분야를 전공하시는 분이 많다는 것도 이 분야의 특징입니다.
그래서 문제는 로봇에 필요한 실시간성 부분을 간과하는 것입니다. 이 내용이 ROS에서도 나타난 것이지요.
단지 로봇에 활용하기 위해서 필요한 것은
실시간 요건을 만족할 수 있도록 만드는 것입니다.
사실 이 내용이 매우 어렵습니다.
ROS는 이 문제를 해결하지 못하여 실시간성은 OROCOS를 활용하도록 유도하는 것입니다.
ROS는 sleep 기능을 활용하여 주기를 제어하도록 되어 있습니다.이는 운영체제에 따라 동작이 달라지는 원인이 되기도 합니다.
OPRoS는 실시간성을 유지하기 위하여 실시간 통신 및 실시간 스케쥴링을 모두 지원하는 것입니다.
OPRoS는 처음에는 sleep 기능을 활용하여 스케쥴링을 하였지만, 최근에는 타이머 기능을 활용하여 스케쥴링을 하고 있는 것으로 알고 있습니다.
이 문제를 해결하기 위해서는 기본적으로 제어/자동화/실시간 시스템을 이해함과 동시에 통신 및 컴퓨터 시스템을 이해하지 못하면 해결할 수가 없습니다.
그래서 과제에서 팀이 필요한 것이지료. 총괄책임자 한 사람이 하는 것이 아니지요.
오해의 정정
말씀하신 내용에 동의합니다. ROS와 OPRoS 모두 장단점이 분명히 있습니다. 말씀하신 실시간성은 ROS가 매우 부족한 점일 것입니다. 또한 사용자의 수/인지도라는 면에서는 OPRoS가 ROS에 비해 매우 부족한 점일 것입니다.
저는 ROS와 OPRoS의 우열이나 장단점에 대해 말씀드린 것이 아니고, unknowny 님과 robotSW 님의 의견에서 ***과제 총괄책임자의 전공***에 대한 의견만 unknowny님의 의견이 보다 옳은 것 같다고 말씀드린 것 입니다.
1. unknowny님 의견: 과제 총괄책임자 분이 로봇과는 거리가 있는, 소프트웨어 아키텍쳐/통신 관련 전공자 분이시라는 겁니다.
2. robotSW님 의견: OPRoS 과제 총괄하시는 분은 제어/자동화/실시간시스템 관련되어 깊이 연구하신 분입니다. 아마 논문도 이와 관련된 내용이 많은 것으로 생각됩니다.
글에 오해가 있게 되어 죄송합니다. 물론 말씀하신대로 과제는 팀이 진행하는 것이니 과제 총괄책임자님의 과거의 세부 연구 주제가 과제 성과의 질적 우수성과 밀접한 인과관계를 가지지는 않을 것 입니다.
----
더불어서 한 가지 질문이 있습니다. OPRoS가 실시간성이 보장된다고 들었습니다. 실시간성을 지원하지 않는 운영체제(예: Windows)에서 커널 패치 없이 어떻게 미들웨어 수준에서 "실시간성"을 보장하나요? Windows에서 실시간성 보장을 위한 상용 소프트웨어(예: IntervalZero RTX)들은 모두 커널 패치를 하는 것 같던데요. 만약 가능하더라도 매우 제한적일 적 같습니다. 예를 들어 OPRoS 이외에 다른 프로세스/서비스/프로그램은 실행하지 않는다와 같이요.
제가 이 분야 비전공자여서 궁금하여 여쭤봅니다.