Do I need a real-time OS for industrial robot controllers ?

Yes and no, depending the hardware structure of your controller.

“Soft real-time OS” is enough except for servo control tasks. If  servo control tasks are responsible for the position, velocity and current control of PMSMs (permanent-magnet synchronous motors), the servo control tasks  have no way of escaping from  “hard real-time OS”.    

 

산업용 로봇에 도입된 OS, RTOS와 그 뒷이야기

초창기의 robot controllers는 OS라는 개념을 사용하지  않았다. 

최초의  commercial industrial robots을 판매하였던 Unimation의 robot controller를 살펴 보자.  그 hardware는, 당시 개발된 microprocessors 중 high computing power를 가진 DEC의 LSI-11 CPU board, DEC의 serial interface board와  parallel I/O board, 자체 개발한 joint servo boards로 구성되어 있었다. Unimation controller의 software는 DEC의 BASIC interepreter와 유사한 syntax를 가진  VAL language와 monitor라 불리우는 commnad interepreter로 구성되어 있었다. monitor와 VAL language는 밀접하게 integrate 되어 있어서 VAL program instruction을 monitor의 command로 실행시킬 수 있었다.   

Unimation  controller 이 후  개발된 industrial robot controllers의 softwares는 대부분 Unimation controller의 software와 유사한 구조를 가지고 있었다.  robot에 따른 전용 software를 개발하여 이를  robot language라 호칭함에 따라  많은 수의 robot langauges가 개발되어 발표되었다. 따라서 robotics 초창기에 사용되었던 robot language는 robot software 또는 robot programming system을 의미한다.   

Unimation 출신 개발자들이 주축이 되어 설립한 Adept는 Unimation controller의 monitor가 가진  기능을 확장하고 task scheduer를 추가하여 이를 robot operating system이라 부르고 있다. 실제 Adept의 software manuals를 보면, robot operating system과 robot language를 구분하여 설명하고 있다.  

1984년 Vincent Hayward는 “realtime” UNIX system를 이용하여 robot controller를 구축하는 방법을 발표하였다. robot을 UNIX system의 device로 보고, 이를 위한 device driver와 응용 software를 C language로 구현하였다.   이 후 robot programming 분야의 연구 방향은  robot language 개발로부터 robot system에  적합한 OS와 C library의 개발로 변화하였으며, robot language라는 연구 topic이 점차 사라지게 되었다.

Vincent Hayward가 Purdue University 에서 구현한 realtime UNIX system을 재현하려면 VAX-11/780 mini computer,   kernel이 수정된 PDP-11의 BSD UNIX OS, custom FIFO boards가 필요하였다. 참고로, Purdue University에서 Richard Paul과 Vincent Hayward에 의해 개발된 robot system은  RCCL이라 명명되었다.

NASA의 space shuttle에 Shuttle Remote Manipulator System (SRMS) (Canada의 DSMA atcon이라는 회사에서  robot arm이 제작되었기 때문에 흔히 canadaarm이라 부른다)의 탑재가 계획되면서 이를 위한 robot controller의 개발이 JPL (NASA 산하의 연구소)과 Canada의 McGill University에서 이루어졌다. McGill univerity는 Multibus 기반의 i386 system과 intel의 iRMX RTOS (realtime OS)에 Purdue University의 RCCL system을 porting 하였다. 이 후 McGill University는  Vincent Hayward를 hire 하였으며, Vincent Hayward는 NASA JPL로부터  연구비를 받아  Kali과 MultiRCCL을 개발하였다.  

Vincent Hayward는 Kali와 MultiRCCL의 OS로서 vxWorks를 선택하였다. BSD Unix를 robot controller의 OS로 사용하려면 kernel 수정이 필요하였다. vxWorks는 그 자체가 RTOS (realtime OS)이기 때문에 kernel 수정 작업을 생략할 수 있으며, vxWorks의 API는 UNIX의 API와 유사하기 때문에  Unix OS에서 개발된 software의 source code를  별다른 수정없이 vxworks에서 build 하여 사용할 수 있다는 장점이 있었다.   

미국 내의 연구 기관과 학교는  미국의 국가 지원  연구비로 수행된 연구 결과를 무료로 제공받아 이를 사용할 수 있는 제도를 가지고 있다  (국방부의 연구비 지원 사업은 제외이다).  미국 내의 여러 연구 기관과 대학교가 MultiRCCL의 source code와 기술 자료를 받아 McGill University와 JPL의 MultiRCCL systems과 유사한 MultiRCCL systems을 구축할 수 있게 됨에 따라 vxWorks와 MultiRCCL은 상당 기간 robotics 연구의 reference software platform으로 사용되었다. 

Unix workstations의 computing power가 향상되고 OS가 BSD UNIX에서 System V Release 4 (SVR4) UNIX로 전환됨에 따라 vxWorks 대신 SVR4 UNIX의 realtime  기능을 이용하여 MultiRCCL을 구동할 수 있게 되었다. 1992년 Sun Microsystems가 SVR4 기반의 OS인 Solaris 2.0을 발표하였으며, 1993년  Silicon Graphics 역시 SVR4 기반의 IRIX  5.0를 발표하였다.  이 후 vxWorks + Motorola 680X0 기반의 platform은 점차 사라지게 되었다. 

초기의 vxworks는 VMEbus의 Motorola 680×0 CPU boards를 main hardware platform으로 지원하였다. 보다 빠른 CPU가 요구되고 PC의 성능이 향상됨에 따라 1998년 Clemson University는 QNX + PC의 조합을 도입하여 QRobot이라는 robot system을 개발하였다. 

CPU의 성능이 지속적으로 향상됨에 따라  joint servo control task을 제외한 tasks의 실행에 non-realtime OS를 사용하는 것이 가능해졌다. 또한  Microsoft의 MS-DOS나  Windows에 realtime module을 추가하거나  Linux에  realtime patch를 적용하여 robot controller를 위한 RTOS로 사용하는 접근 방법도 존재한다. 산업용 로봇 제어기의 software 구조는 이미 확립되어 있으며, 각 기능에 따른 computing power 의 요구량 역시 이미 계산되어 있다.  robot controller의 경우, RTOS 자체의 성능 비교는 의미가 없다고 말할 수 있다.  

사용자가 그다지 많지 않고 제공되는 예제가 충분하지  않은 RTOS를 선택하면,  자신의 program에 RTOS의  function을  추가할 때마다  test program을 작성해서 그 function의 동작을 일일히 확인해 보는 덫에 빠지게 된다. Unix/Linux system programming과  OS, kernel에 대한 이해가 부족하면, RTOS의 manual에서 사용하는 용어와 개념을 이해할 수 없으며 자신이 작성한 software를 충분히 test 할 수 없는 경우가 발생한다.

“software realiablity”는 대부분의 산업용 로봇 개발자들이 생각 조차 하지  않는 단어이며, 언급하지 않으려는 단어이기도 하다. 자신이 이해할 수 없는 commercial 또는 open-source  RTOS를 밑에 깔아 놓고  그 위에 자신이 나름대로 개발한 software을 실행시킨다면, 문제가 발생하였을 때 그 원인을 쉽게 찾아 낼 수 있을까 ?

industrial robots의 오동작 조건은 찾기가 어렵고 재현이 되지 않는 경우가 대부분이다.  industrial robots이 작업 중 정지하면, 생산 라인 전체가 정지되는 경우도 있기 때문에 검증되지 않은 robots은 구매하지 않으려는 경향이 있다. 산업 현장에서는, robots의 accuracy나 repeatibility 보다 reliability가 더 중요할 수도 있다.