OpenRTM-aist는 컴포넌트를 개발하고 싶은 유저(컴포넌트 디벨로퍼)가 가지는 기존의 소프트웨어 자산, 혹은 새롭게 작성한 소프트웨어를 용이하게 RT컴포넌트(RTC)화하기 위한 프레임 워크를 제공합니다. 컴포넌트 작성의 대략의 흐름은 아래의 그림과 같습니다.
RT컴포넌트의 개발 흐름
컴포넌트 개발자는 기존의 소프트웨어 자산의 라이브러리 함수·클래스 라이브러리 등을 컴포넌트 프레임 워크에 묻어 컴포넌트를 작성합니다. 이렇게 하는 것으로 기존의 소프트웨어 자원을 소프트웨어 부품인 RT컴포넌트로서 작성해 두어, 여러가지 장면에서 재이용할 수 있게 됩니다. 작성된 RT컴포넌트는, 네트워크상의 적절한 장소에 배치하고, 분산 오브젝트로서 네트워크상의 임의의 장소로부터 이용할 수 있습니다.
그림에 나타내도록(듯이), RT컴포넌트 체제에 준거해 작성된 RT컴포넌트는 크게 나누어 2개의 바이노리필드로서 작성할 수 있습니다.스탠드얼론 RT컴포넌트 (Standalone RT-Component)는, 단일 파일로 그대로 실행할 수 있는 실행 형식의 바이너리입니다. loadable module RT컴포넌트 (Loadable Module RT-Component)는 동적으로 로드 가능한 loadable module 형식의 바이노리필드입니다. RT컴포넌트는 이러한 2개의 형식에서 작성, 배포, 실행할 수 있습니다.
RTC프로그래밍의 기초
통상의프로그래밍과 RT컴포넌트의프로그래밍에는, 몇개의 큰 차이가 있습니다.
main 함수가 없는 프로그램
RT컴포넌트의 프로그램에는 통상의 프로그램과는 달라, main 함수가 없습니다. 대신에 1개의 RT컴포넌트는, 통상 있는 특별한 base class을 계승한 하나의 클래스로서 실장됩니다.
RT컴포넌트에 시키고 싶은 처리는, 그 base class의 멤버 함수(메소드)를 오버라이드(override) 하는 형태로 기술합니다. 예를 들면, 초기화와 같은 처리는, onInitialize라고 하는 함수안에 기술합니다.혹은, 종료시에 실시하고 싶은 처리이면, onFinalize 라고 하는 함수안에 기술합니다.
ReturnCode_t MyComponent::onInitialize()
{
// 초기화 처리 등
}
ReturnCode_t MyComponent::onFinalize()
{
// 종료 처리 등
}
그럼, 여기서 쓴 초기화 처리나, 종료 처리는 언제 실행되는 것입니까? 그것을 알기 위해서는, RT컴포넌트의 라이후사이크루를 알 필요가 있습니다.
컴포넌트·라이후사이크루
어느 RT컴포넌트가 태어나고 나서 죽을 때까지의 일련의 흐름을, 컴포넌트의 라이후사이크루라고 부릅니다.
컴포넌트에는 기본적으로
생성 상태(Created)
활동 상태(Alive)
종료 상태
의 3개 상태를 가집니다. (Alive 상태는 내부에 한층 더 상태를 가집니다(후술).)
컴포넌트는 1개의 클래스인 것은 위에서 말했습니다. 따라서, 컴포넌트가 생성되는 것은, 오브젝트(인스턴스)가 생성되는 것으로 거의 같습니다. 통상, RT컴포넌트는 매니저(RTC 매니저)에 의해서 생성되어 이후 매니저가 RT컴포넌트의 라이후사이크루를 관리합니다.
구체적으로는, 매니저는 RT컴포넌트의 인스턴스 생성 후, 위에서 말한 onInitialize 함수를 콜 합니다. 또, RT컴포넌트가 종료할 때, 매니저는 onFinalize 함수를 콜 합니다. 이와 같이, RT컴포넌트의 라이후사이크루안의 특정의 타이밍에 할당할 수 있었던 처리(이것을 액션이라고 부른다) 마다, 필요한 처리를 기술하는 것으로, RT컴포넌트의프로그래밍을 실시합니다.
실행 문맥
통상 프로그램을 실행하면 스렛드를 할당할 수 있어 그 스렛드가 프로그램으로서 기술된 처리를 실행합니다. 로봇을 제어하는 프로그램에서는, 통상 스렛드에 의해 실행되는 루프(제어 루프나 처리 루프)를 가져, 센서 데이터를 처리하거나 액츄에이터를 계속 제어합니다. 이러한, 무엇인가를 처리하거나 제어하거나하기 위한 주된 처리를 RT컴포넌트에서는 코어 논리라고 부릅니다.
RT컴포넌트는, 생성되어 Alive 상태가 되면 통상 하나의 스렛드를 할당할 수 있어 RT컴포넌트로서의 메인의 처리(코어 논리)를 실행합니다. 이 스렛드를 RT컴포넌트에서는 실행 문맥(ExecutionContext)이라고 부릅니다. 실제로는, 실행 문맥은 스렛드 그 자체가 아니고, 스렛드를 추상적으로 표현한 것으로 실행 주기나 상태를 가집니다. 즉, RT컴포넌트가 생성되면 실행 문맥이 RT컴포넌트에 관련지을 수 있어 코어 논리가 구동되는 것으로, RT컴포넌트가 어떠한 처리(예를 들면 로봇을 제어하는 등)를 실시합니다.
RTC 상태 천이
위에서 말한 것처럼, RT컴포넌트는 상태를 가져, 그 상태나 천이에 할당할 수 있었던 액션으로서 처리를 기술합니다. 밑그림은 RT컴포넌트 상태 천이도(UML의 스테이트 머신도)를 나타내고 있습니다.
RT컴포넌트 상태 천이
Created와 Alive는 RT컴포넌트 상태입니다. Alive 상태안에도 몇개의 상태가 존재하고 있습니다.
스렛드의 정지상태와 실행 상태
우선, Alive 상태 내부의 상부의 Stopped와 Running 상태에서 보고 갑니다.
스렛드의 정지상태와 실행 상태
이것은, 실행 문맥을 스렛드로서 보았을 때, 스렛드가 정지중(Stopped)이나 실행중(Running)인지를 나타내는 상태입니다.
정지상태(Stopped)에 있는 실행 문맥이 start 이벤트를 받으면, RT컴포넌트의 onStartup를 실행해 실행 상태(Running)에 천이 합니다. 반대로 stop 이벤트에 의해, 실행 문맥은 RT컴포넌트의 onShutdown를 실행해 정지상태(Stopped) 상태에 천이 합니다.
코어 논리의 액션은, 실행 상태(Running) 상태 때 마셔 실행되어 정지상태에 대해 모든 액션은 실행되지 않습니다.
액티브·비액티브 상태
Alive 상태내의 하단은 코어 논리의 액티브(Active)·비액티브(Inactive)·에러(Error)에 관한 상태 천이입니다.
RT컴포넌트 생성 직후는, RT컴포넌트는 비액티브 상태(Inactive)에 있습니다. RT컴포넌트를 액티브화하면, RT컴포넌트의 액션인 onActivate가 콜 되어 액티브 상태에 천이 합니다. 액티브 상태에 있는 동안, 통상 RT컴포넌트의 액션 onExecute가 반복해 실행계속 됩니다. 통상은 이 onExecute내에서, RT컴포넌트의 메인의 처리를 실시합니다. 예를 들면, 센서로부터 데이터를 읽어들여 다른 컴포넌트에 보내거나 다른 컴포넌트로부터 받은 데이터에 근거해 모터를 제어하거나라고 한, 로봇에 있어 기본적인 반복 처리는 onExecute에 기술하게 되겠지요.
RT컴포넌트는 비액티브화 되는지, 에러가 발생할 때까지 액티브 상태에 계속 머뭅니다. 비액티브화 되는 경우는 onDeactivate가 콜 되어 비액티브 상태에 천이 합니다. 액티브 상태의 처리 중(안)에서 어떠한 에러가 발생했을 경우, RT컴포넌트의 액션인 onAborting가 콜 되어 에러 상태(Error)에 천이 합니다.
에러 상태에 천이 했을 경우, 외부로부터 리셋트를 할 때까지 에러 상태에 계속 머물어 onError가 콜 계속 됩니다. 리셋트를 하면, onReset가 콜 됩니다. onReset의 처리가 성공하면 비액티브 상태(Inactive)에 천이 해, 다시 액티브 상태가 될 수 있습니다만, onReset가 실패했을 경우는, 에러 상태에 계속 머뭅니다.
비액티브 상태·액티브 상태·에러 상태
액션의 정리
RT컴포넌트 개발자의 주된 일은, 자신이 작성하려고 하는 컴포넌트에서는, 지금까지 말해 온 RT컴포넌트의 각 상태마다 어떤 처리를 하면 좋은 것인지를 생각해 각각의 액션에 대응하는 함수를 실장하는 것입니다. 즉, 자신이 작성하는 컴포넌트에 필요한on???라고 하는 함수만을 오버라이드(override) 해, 함수의 내용을 기술하면 좋습니다.
RTC프로그래밍의 흐름
OpenRTM-aist는 컴포넌트를 개발하고 싶은 유저(컴포넌트 디벨로퍼)가 가지는 기존의 소프트웨어 자산, 혹은 새롭게 작성한 소프트웨어를 용이하게 RT컴포넌트(RTC)화하기 위한 프레임 워크를 제공합니다. 컴포넌트 작성의 대략의 흐름은 아래의 그림과 같습니다.
컴포넌트 개발자는 기존의 소프트웨어 자산의 라이브러리 함수·클래스 라이브러리 등을 컴포넌트 프레임 워크에 묻어 컴포넌트를 작성합니다. 이렇게 하는 것으로 기존의 소프트웨어 자원을 소프트웨어 부품인 RT컴포넌트로서 작성해 두어, 여러가지 장면에서 재이용할 수 있게 됩니다. 작성된 RT컴포넌트는, 네트워크상의 적절한 장소에 배치하고, 분산 오브젝트로서 네트워크상의 임의의 장소로부터 이용할 수 있습니다.
그림에 나타내도록(듯이), RT컴포넌트 체제에 준거해 작성된 RT컴포넌트는 크게 나누어 2개의 바이노리필드로서 작성할 수 있습니다.스탠드얼론 RT컴포넌트 (Standalone RT-Component)는, 단일 파일로 그대로 실행할 수 있는 실행 형식의 바이너리입니다. loadable module RT컴포넌트 (Loadable Module RT-Component)는 동적으로 로드 가능한 loadable module 형식의 바이노리필드입니다. RT컴포넌트는 이러한 2개의 형식에서 작성, 배포, 실행할 수 있습니다.
RTC프로그래밍의 기초
통상의프로그래밍과 RT컴포넌트의프로그래밍에는, 몇개의 큰 차이가 있습니다.
main 함수가 없는 프로그램
RT컴포넌트의 프로그램에는 통상의 프로그램과는 달라, main 함수가 없습니다. 대신에 1개의 RT컴포넌트는, 통상 있는 특별한 base class을 계승한 하나의 클래스로서 실장됩니다.
RT컴포넌트에 시키고 싶은 처리는, 그 base class의 멤버 함수(메소드)를 오버라이드(override) 하는 형태로 기술합니다. 예를 들면, 초기화와 같은 처리는, onInitialize라고 하는 함수안에 기술합니다.혹은, 종료시에 실시하고 싶은 처리이면, onFinalize 라고 하는 함수안에 기술합니다.
ReturnCode_t MyComponent::onInitialize() { // 초기화 처리 등 } ReturnCode_t MyComponent::onFinalize() { // 종료 처리 등 }그럼, 여기서 쓴 초기화 처리나, 종료 처리는 언제 실행되는 것입니까? 그것을 알기 위해서는, RT컴포넌트의 라이후사이크루를 알 필요가 있습니다.
컴포넌트·라이후사이크루
어느 RT컴포넌트가 태어나고 나서 죽을 때까지의 일련의 흐름을, 컴포넌트의 라이후사이크루라고 부릅니다.
컴포넌트에는 기본적으로
의 3개 상태를 가집니다. (Alive 상태는 내부에 한층 더 상태를 가집니다(후술).)
컴포넌트는 1개의 클래스인 것은 위에서 말했습니다. 따라서, 컴포넌트가 생성되는 것은, 오브젝트(인스턴스)가 생성되는 것으로 거의 같습니다. 통상, RT컴포넌트는 매니저(RTC 매니저)에 의해서 생성되어 이후 매니저가 RT컴포넌트의 라이후사이크루를 관리합니다.
구체적으로는, 매니저는 RT컴포넌트의 인스턴스 생성 후, 위에서 말한 onInitialize 함수를 콜 합니다. 또, RT컴포넌트가 종료할 때, 매니저는 onFinalize 함수를 콜 합니다. 이와 같이, RT컴포넌트의 라이후사이크루안의 특정의 타이밍에 할당할 수 있었던 처리(이것을 액션이라고 부른다) 마다, 필요한 처리를 기술하는 것으로, RT컴포넌트의프로그래밍을 실시합니다.실행 문맥
통상 프로그램을 실행하면 스렛드를 할당할 수 있어 그 스렛드가 프로그램으로서 기술된 처리를 실행합니다. 로봇을 제어하는 프로그램에서는, 통상 스렛드에 의해 실행되는 루프(제어 루프나 처리 루프)를 가져, 센서 데이터를 처리하거나 액츄에이터를 계속 제어합니다. 이러한, 무엇인가를 처리하거나 제어하거나하기 위한 주된 처리를 RT컴포넌트에서는 코어 논리라고 부릅니다.
RT컴포넌트는, 생성되어 Alive 상태가 되면 통상 하나의 스렛드를 할당할 수 있어 RT컴포넌트로서의 메인의 처리(코어 논리)를 실행합니다. 이 스렛드를 RT컴포넌트에서는 실행 문맥(ExecutionContext)이라고 부릅니다. 실제로는, 실행 문맥은 스렛드 그 자체가 아니고, 스렛드를 추상적으로 표현한 것으로 실행 주기나 상태를 가집니다. 즉, RT컴포넌트가 생성되면 실행 문맥이 RT컴포넌트에 관련지을 수 있어 코어 논리가 구동되는 것으로, RT컴포넌트가 어떠한 처리(예를 들면 로봇을 제어하는 등)를 실시합니다.
RTC 상태 천이
위에서 말한 것처럼, RT컴포넌트는 상태를 가져, 그 상태나 천이에 할당할 수 있었던 액션으로서 처리를 기술합니다. 밑그림은 RT컴포넌트 상태 천이도(UML의 스테이트 머신도)를 나타내고 있습니다.
Created와 Alive는 RT컴포넌트 상태입니다. Alive 상태안에도 몇개의 상태가 존재하고 있습니다.
스렛드의 정지상태와 실행 상태
우선, Alive 상태 내부의 상부의 Stopped와 Running 상태에서 보고 갑니다.
이것은, 실행 문맥을 스렛드로서 보았을 때, 스렛드가 정지중(Stopped)이나 실행중(Running)인지를 나타내는 상태입니다.
정지상태(Stopped)에 있는 실행 문맥이 start 이벤트를 받으면, RT컴포넌트의 onStartup를 실행해 실행 상태(Running)에 천이 합니다. 반대로 stop 이벤트에 의해, 실행 문맥은 RT컴포넌트의 onShutdown를 실행해 정지상태(Stopped) 상태에 천이 합니다.
코어 논리의 액션은, 실행 상태(Running) 상태 때 마셔 실행되어 정지상태에 대해 모든 액션은 실행되지 않습니다.
액티브·비액티브 상태
Alive 상태내의 하단은 코어 논리의 액티브(Active)·비액티브(Inactive)·에러(Error)에 관한 상태 천이입니다.
RT컴포넌트 생성 직후는, RT컴포넌트는 비액티브 상태(Inactive)에 있습니다. RT컴포넌트를 액티브화하면, RT컴포넌트의 액션인 onActivate가 콜 되어 액티브 상태에 천이 합니다. 액티브 상태에 있는 동안, 통상 RT컴포넌트의 액션 onExecute가 반복해 실행계속 됩니다. 통상은 이 onExecute내에서, RT컴포넌트의 메인의 처리를 실시합니다. 예를 들면, 센서로부터 데이터를 읽어들여 다른 컴포넌트에 보내거나 다른 컴포넌트로부터 받은 데이터에 근거해 모터를 제어하거나라고 한, 로봇에 있어 기본적인 반복 처리는 onExecute에 기술하게 되겠지요.
RT컴포넌트는 비액티브화 되는지, 에러가 발생할 때까지 액티브 상태에 계속 머뭅니다. 비액티브화 되는 경우는 onDeactivate가 콜 되어 비액티브 상태에 천이 합니다. 액티브 상태의 처리 중(안)에서 어떠한 에러가 발생했을 경우, RT컴포넌트의 액션인 onAborting가 콜 되어 에러 상태(Error)에 천이 합니다.
에러 상태에 천이 했을 경우, 외부로부터 리셋트를 할 때까지 에러 상태에 계속 머물어 onError가 콜 계속 됩니다. 리셋트를 하면, onReset가 콜 됩니다. onReset의 처리가 성공하면 비액티브 상태(Inactive)에 천이 해, 다시 액티브 상태가 될 수 있습니다만, onReset가 실패했을 경우는, 에러 상태에 계속 머뭅니다.
액션의 정리
RT컴포넌트 개발자의 주된 일은, 자신이 작성하려고 하는 컴포넌트에서는, 지금까지 말해 온 RT컴포넌트의 각 상태마다 어떤 처리를 하면 좋은 것인지를 생각해 각각의 액션에 대응하는 함수를 실장하는 것입니다. 즉, 자신이 작성하는 컴포넌트에 필요한on???라고 하는 함수만을 오버라이드(override) 해, 함수의 내용을 기술하면 좋습니다.
이하에, 컴포넌트의 액션의 함수로 역할을 나타냅니다.