OpenRTM-aist(C++버전, Python버전, Java버전)에 관한 문제해결을 정리했습니다.
OpenRTM-aist(공통)
OS공통
컴포넌트는 분명히 기동되고 있는데도 좀비 오브젝트로 표시됩니다.
컴포넌트는 기동하고 있고 네임 서버에도 등록되어 있는데 RTSystemEditor의 네임 서비스 뷰 상에서는 좀비 오브젝트로 표시되고 있으며 시스템 에디터에 드래그 & 드롭해도 아무것도 표시가 되지 않습니다.
[원인]컴포넌트를 기동한 호스트에 도달할 수 없음
RTSystemEditor가 동작하고 있는 PC로부터 컴포넌트를 기동한 호스트에 어떠한 이유로 도달 되어 있지 않을 가능성이 있습니다.
먼저, RTSystemEditor가 기동하고 있는 PC에서 컴포넌트를 기동한 호스트에 대해서 ping이 도달하는가를 확인해 주십시오 예를 들어 이하의 3대의 호스트A, B, C가 있다고 가정합니다.
hostA: 컴포넌트가 기동하고 있는 호스트
hostB: 네임 서버가 기동하고 있는 호스트
hostC: RTSystemEditor가 동작하는 호스트
이러한 호스트의 네트워크가 이하와 같이 구성되어 있어, [hostA]-(네트워크I)-[hostB]-(네트워크I)-[hostC]
한편 hostB가 네트워크I와 네트워크II사이를 적절하게 루팅 하도록 설정되어 있지 않으면 hostC에서 hostA에는 도달할 수 없습니다.
이러한 경우는 hostB를 적절히 설정해 hostC에서 hostA에 도달할 수 있도록 할 필요가 있습니다.
[원인]컴포넌트를 기동한 호스트에서 방화벽이 유효로 설정되어 있다.
컴포넌트가 동작하고 있는 호스트에서 방화벽이 동작하고 있는 경우, RTSystemEditor와 컴포넌트가 통신하지 못하고 이러한 현상이 발생하는 경우가 있습니다.
방화벽의 설정을 재검토하거나 OFF로 하는 등 외부에서부터 컴포넌트의 통신이 가능하도록 해 주십시오.
Windows
인스톨러 실행중에 「…권한이 없습니다.」라고 표시되고 인스톨을 진행할 수 없습니다.
Administrator권한을 갖는 유저로 로그인해서 인스톨 작업을 해주십시오.
컴포넌트가 네임 서비스에 등록되지 않습니다.
네임 서버, 컴포넌트를 기동 후 RTSystemEditor등으로 네임 서버에 접속했을 때 컴포넌트가 등록되어 있지 않은 경우가 있습니다.
이런 경우는
먼저 로그 레벨을 최고로 하기 위해 rtc.conf에
logger.log_level:PARANOID
을 설정해 컴포넌트를 기동해 주십시오.
컴포넌트의 로그에
naming_svc NameServer connection succeeded: corba/호스트 명:포트 번호
라는 메세지가 없다면 네임 서버에 등록이 실패하고 있습니다.
이러한 경우, 이하의 원인을 생각할 수 있습니다.
rtc.conf의 corba.nameservers가 올바르게 설정되어 있지 않다.
컴포넌트가 읽어들인 rtc.conf가 올바르게 설정되어 있는지를 확인해 주십시오. 이용하려고 하는 네임 서버를 openrtm.aist.go.jp라는 호스트 명으로 가정하면 이하의 행이 rtc.conf에 포함되어 있어야 합니다.
corba.nameservers: openrtm.aist.go.jp
또, 네임 서버를 포트 번호를 지정해서 기동한 경우는 포트 번호도 지정할 필요가 있습니다. 네임 서버 기동시에 지정한 포트 번호가 1234번인 경우, 이하와 같이 설정할 필요가 있습니다.
corba.nameservers: openrtm.aist.go.jp:1234
포트 번호가 지정되어 있지 않은 경우는 디폴트 포트번호 2809가 사용됩니다. 이것은 omniORB의 네임 서버(omniNames)의 디폴트 포트번호 입니다. 만약 omniORB 이외의 네임 서버를 사용하고 있는 겨우는 주의해 주십시오.
컴포넌트를 기동한 호스트에서 네임 서버를 기동한 호스트에 네트워크 연결이 되지 않습니다.
컴포넌트를 기동한 호스트에서 네임 서버를 기동한 호스트에 네트워크 연결이 되는가 확인해 주십시오.
먼저, ping이 도달하는지를 확인합니다. 만약 도달하지 않는다면 네트워크의 설정을 재설정해 주십시오.
ping이 도달해도 방화벽 등으로 연결이 금지되어 있는 가능성이 있습니다. 먼저 네임 서버를 기동한 호스트 측의 방화벽의 설정을 재설정해 주십시오. 가장 간단한 방법은 방화벽을 OFF로 하는 것입니다. 각 OS나 방화벽의 설정방법을 참조해 주십시오.
네트워크 인터페이스가 2개 이상 존재합니다.
호스트에 네트워크 인터페이스가 2개 이상 있는 경우, CORBA에 어느 쪽의 인터페이스를 사용할 것인지를 가르쳐 줄 필요가 있습니다.
이것은 네임 서버 측, 컴포넌트 측 모두 고려해야 합니다.
만약 각각의 호스트가 2개씩 인터페이스를 갖고 있고, 각 인터페이스의 어드레스가 이하와 같이 설정되어 있다고 가정합니다.(mask는 255.255.255.0라고 가정) 네임 서버host: eth0:192.168.0.1, eth1:192.168.100.1 컴포넌트host: eth0:192.168.0.2, eth1:192.168.11.96
이러한 경우 네임 서버host와 컴포넌트 host는 192.168.0의 네트워크에 연결되어 있을 것입니다.
따라서, 네임 서버에는 eth0:192.168.0.1 컴포넌트에는 eth0:192.168.0.2
의 인터페이스를 사요하도록 가르쳐 줄 필요가 있습니다.
네임 서버 측에서는 네임 서버를 기동할 때 OMNIORB_USEHOSTNAME라는 환경변수를 설정할 필요가 있습니다.
(csh계)
> setenv OMNIORB_USEHOSTNAME 192.168.0.1
(bash계)
> export OMNIORB_USEHOSTNAME=192.168.0.1
> rtm-naming 혹은 omniNames 로 네임 서버를 기동
직접 rtm-naming (UNIX계) 혹은 rtm-naming.bat (Windows)에 써도 좋을 것입니다.
한편, 컴포넌트 측은 rtc.conf에 corba.endpoint의 설정을 기술하는 것으로 사용하는 인터페이스를 지정할 수 있습니다.
corba.endpoint: 인터페이스 IP어드레스:포트 번호
corba:endpoint: 192.168.0.2: (포트 번호를 지정하지 않은 경우)
corba:endpoint: 192.168.0.2:1234 (포트 번호를 지정한 경우)
포트 번호는 특별히 지정하지 않아도 됩지만, IP어드레스의 뒤의:(콜론)을 잊지않고 써 주십시오.
OpenRTM-aist(C++버전)
Windows
어플리케이션 에러「어플리케이션을 정상적으로 초기화하지 못했습니다.…」
네임 서버를 기동하려고 rtm-naming.bat을 실행하면, 위의 에러가 나오는 경우가 있습니다. 이 에러는 기동 환경상에 VC++라이브러리의 런타임 컴포넌트가 없기 때문에 발생합니다. VC++관련 개발 환경（Microsoft Visual Studio 、Visual C++ Express 등）을 인스톨하고 있지 않은 환경에서는 OpenRTM-aist(C++버전)을 동작시킬수 없기 때문에 반드시 VC++관련 개발 환경을 인스톨해 주십시오.
OpenRTM-aist(C++버전)에서는 VC8（VS2005）를 베이스로한 것과 VC9（VS2008）를 베이스로 한 것이 있습니다. OpenRTM-aist-X.X.X-jp_vc8.msi（X.X.X은 버전)등의 VC8베이스의 인스톨러를 사용한 경우는 Microsoft Visual C++ 2005 SP1 재배포 가능 패키지(x86) 를、OpenRTM-aist-X.X.X-jp_vc9.msi（X.X.X은 버전)등의 VC9베이스의 인스톨러를 사용한 경우에는Microsoft Visual C++ 2008 재배포 가능 패키지 (x86) 를 인스톨해 주십시오.
「이 어플리케이션의 구성이 올바르지 않기 때문에 어플리케이션을 개시할 수 없습니다.…」
샘플의 RT컴포넌트 등을 기동하려고 xxxComp.exe을 실행하면 위와 같은 에러가 나오는 경우가 있습니다. 이 에러는 기동 환경상에 VC++라이브러리의 런타임 컨포넌트가 없기때문에 발생합니다. VC++관련 개발 환경（Microsoft Visual Studio 、Visual C++ Express 등）을 인스톨하고 있지 않은 환경에서는 OpenRTM-aist(C++버전)을 동작시킬수 없기 때문에 반드시 VC++관련 개발 환경을 인스톨해 주십시오.
OpenRTM-aist(C++버전)에서는 VC8（VS2005）를 베이스로한 것과 VC9（VS2008）를 베이스로 한 것이 있습니다. OpenRTM-aist-X.X.X-jp_vc8.msi（X.X.X은 버전)등의 VC8베이스의 인스톨러를 사용한 경우는 Microsoft Visual C++ 2005 SP1 재배포 가능 패키지(x86) 를、OpenRTM-aist-X.X.X-jp_vc9.msi（X.X.X은 버전)등의 VC9베이스의 인스톨러를 사용한 경우에는Microsoft Visual C++ 2008 재배포 가능 패키지 (x86) 를 인스톨해 주십시오.
Visual C++ 2008 Express Edition에서 빌드 시 「'windows.h'르 찾을 수 없습니다.」라는 에러
Visual C++ 2008 Express Edition에서 빌드 시 다음과 같은 에러가 나오는 경우가 있습니다.
>c:\program files\omniorb\include\omnithread\nt.h(35) : fatal error C1083: include 파일을 열 수 없습니다.'windows.h': No such file or directory
이것은 １．Microsoft Platform SDK가 인스톨되어 있지 않음, 또는２．include 파일 경로・라이브러리 경로의 설정미비가 원인이라고 생각할 수 있습니다.
１．Microsoft Platform SDK가 인스톨되어 있지 않음
대응방법：
Microsoft Platform SDK를 인스톨한다. 그 때、여기를 참고해 수십시오. 또는 다음의 ２．에 따라 주십시오.
２．include 파일 경로・라이브러리 경로의 설정미비
대응방법：
인스톨하는 순서 등의 관계로 Visual C++ 2008 Express Edition의 설치 디렉토리와는 다른 장소에 にMicrosoft Platform SDK가 인스톨되는 이유로 인해 Visual C++ 2008 Express Edition의 컴파일러가 Microsoft Platform SDK의 include파일이나 라이브러리를 참조하지 못하는 경우가 있습니다. 이러한 경우는 include 파일 서치 경로나 라이브러리 서치 경로에 Microsoft Platform SDK의 인스톨 디렉토리를 추가하는 것으로 문제를 해결할 수 있습니다.
include 파일 서치 경로의 추가 방법
Visual C++ 2008 Express Edition의 메뉴바→「도구」→「옵션」을 선택해, 「옵션」윈도우를 엽니다. 왼쪽 트리뷰에서 「프로젝트 및 솔루션」→「VC++디렉터리」를 선택합니다.
오른쪽 상단의 풀다운 메뉴「다음 파일의 디렉터리 표시」를 「포함 파일」로 해서 Microsoft Platform SDK의 include 파일의 디렉토리（예를들어, 「C:\Program Files\Microsoft Platform SDK\Include」）를 include 파일의 서치 경로에 추가합니다.
라이브러리 서치 파일의 추가방법
위와 같은 방법으로「옵션」의 왼쪽 트리뷰에서「VC++디렉터리」를 선택한 상태에서, 우측상단의 풀다운 메뉴「다음 파일의 디렉터리 표시」를 「라이브러리 파일」로 하고 Microsoft Platform SDK의 라이브러리 파일의 디렉토리（예를들어, 「C:\Program Files\Microsoft Platform SDK\Lib」）을 라이브러리 파일의 서치 경로에 추가합니다.
또한 서치 경로의 구체적인 추가 방법 등은 Visual C++ 2008 Express Edition의 도움말 등을 참고해주십시오.
rtm-naming의 실행에서 에러 발생
증상: rtm-naming.bat을 실행하면 어플리케이션 에러가 발생한다.
VC++관련 라이브러리가 인스톨 되어 있지 않을 가능성이 있습니다.
증상：rtm-naming.bat을 실행해도 검은 창（커맨드 프롬프트 화면）가 순간 열렸다 닫힙니다.
[원인]omniORB가 인스톨 되어 있지 않다.
rtm-naming.bat내에서는 통상omniORB의 네임 서버 omniNames.exe를 실행합니ㅏ.
omniORB가 인스톨 되어 있지 않으면 omniNames.exe도 인스톨 되지 않기 때문에, 네임 서버를 실행할 수 없습니다.
다운로드 페이지에서 omniORB를 다운로드해서 인스톨 해 주십시오.
[원인]log디렉토리의 경로 중에 2바이트 문자가 포함되어 있다.
rtm-naming.bat내에서는 통상omniORB의 네임 서버 omniNames.exe를 이해와 같이 실행합니다.
omniNames.exe -start 2809 -logdir %TEMP%
통상 환경 변수 %TEMP% 는 유저의 템프 디렉토리
C:\Documents and Settings\ユーザ名\Local Settings\Temp
를 가리킵니다. 여기에서 유저 명이 한글인 경우, omniNames가 로그 파일을 정상적으로 작성할 수 없기 때문에 실행하지 못하고 종료합니다.
대응방법으로 이하의 3가지 방법을 참고해 주십시오.
한글 유저 명을 사용하지 않는다.
한글을 사용하지 않는 유저를 새로 작성해 그 환경에서 실행한다.
rtm-naming.bat을 변경한다.
C:\Program Files\OpenRTM-aist\[버전 번호]\bin의 아래에 있는 rtm-naming.bat중 아래의 부분
%cosnames% -start %port% -logdir %TEMP%\
을
%cosnames% -start %port% -logdir [경로에 한글을 포함하지 않는 로그 디렉토리]
로 변경합니다. 경로에 한글을 포함하지 않는 로그 디렉토리는 자신에게 작성할 수 있는 디렉토리로 안전한 위치로 해주십시오. 예를들어 C:\tmp 등.
Java버전의 orbd를 사용
OpenRTM-aist의 Java버전과 JDK를 인스톨하면 스타트 메뉴의 Java버전 examples 중에서 start-orbd.vbs가 나타납니다. 이것은 JDK에 부속하는 CORBA네임 서버를 기동하는 스크립트입니다.
이 네임 서버에는 omniNames과 같은 한글 경로의 문제는 존재하지 않기 때문에 이것을 사용하는 것으로 유저명이 한글이어도 네임 서버를 기동할 수 있습니다.
Unix
패키지의 자동 인스톨에서 다운로드 에러가 발생한다.
OpenRTM-aist에 부속하는 자동 인스톨러는 패키지의 유무와 버전을 확인해 적당한 패키지가 인스톨 되어 있지 않은 경우에 각 패키지의 다운로드 사이트로 부터 다운로드 및 가공하는 것입니다. 이 때문에 자동 인스톨러로 인스톨할 경우에는 컴퓨터를 반드시 인터넷에 연결해 주십시오.
네트워크 접속이 정상인데도 다운로드 에러가 발생할 경우, 회선의 혼잡등으로 다운로드에 실패하는 경우가 있고 다운로드 사이트 측에서 파일의 위치나 이름을 변경했을 가능성도 있습니다. 전자의 경우는 시간대등을 늦추어 다시 자동 인스톨러를 실행해주십시오. 후자의 경우는, 해당하는 패키지를 찾아 각각을 다운로드해 수동 인스톨하던지 자동 인스톨러의 다운로드 원 주소를 수정하고 나서 다시 기동해주십시오
또한, 다운로드 사이트 측의 변경이 있을 경우 변경정보를 저희에게 연락을 해주시면 감사하겠습니다. 협력 부탁드리겠습니다.
configure를 실행했지만 에러가 발생해 종료한다.
configure에러의 대부분은 필요한 패키지가 발견되지 않을 때에 발생합니다. 에러가 났을 경우는 필요한 패키지가 인스톨 되어 있는지 autoconf를 찾을 수 있는 디렉토리에 헤더, 라이브러리가 인스톨 되어 있는지를 확인해 주십시오.
make를 실행해도 빌드가 완료되지 않음. 또는 make 실행에러가 발생.
패키지의 인스톨 또는 OpenRTM-aist（C++）의 빌드가 불완전한 가능성이 있습니다. 한번더 패키지의 자동 인스톨러를 기동하고 패키지의 인스톨부터 다시 해 주십시오. 패키지의 인스톨 중에 처리 화면에 어떠한 에러 메세지가 나왔을 경우,해당하는 패키지만을 수동으로 인스톨 하거나 한다음 configure를 실행해 주십시오. configure를 실행하고 에러 메세지가 나오지 않는 것을 확인하고 나서, 다시 make를 실행해 빌드를 완료해 주십시오.
OpenRTM-aist의 인스톨에 실패한다.
이전 버전의 OpenRTM-aist이 완전히 삭제되지 않았을 경우, 새 버전을 인스톨 할 수 없습니다. 이전 버전을 완전히 삭제한 다음 다시 인스톨을 합니다.
Vine・Fedora・ubuntu・debian공통：
pkg_install_XXXX.sh 을 이용해 삭제.
>su
#pkg_install_XXXX.sh -u
삭제의 허가를 요구하기 때문에, y 를 입력해 나가면서 완료시킵니다. 또는 다음의 순서를 따릅니다.
Ubuntu、Debian등의 디스크리뷰션에서 apt-get이나 pkg_install_ubuntu.sh, pkg_install_debian.sh을 사용해 인스톨 작없을 하고 있으면 다음과 같이 CD를 요구하는 경우가 있습니다. 미디어 변경:
'Ubuntu 7.10 _Gutsy Gibbon_ Japanese Remix - Release i386 (20071018)'
위와 같은 라벨의 디스크를 드라이브 '/cdrom/'에 넣고 enter를 눌러주십시오.
물론, CD를 준비하면 좋겠지만 여러가지 사정에 의해 준비할 수 없는 경우의 처리 방법을 기술합니다.
이런 경우에는 우선, C-c(Ctrl+c)를 입력해 인스톨 작업을 중단하고 이하의 순서로 인스톨 작업을 다시해주십시오.
1./etc/apt/sources.list 을 편집
/etc/apt/sources.list 의 앞부분에
deb cdrom:[Ubuntu 7.10 _Gutsy Gibbon_ Japanese Remix - Release i386 (20071018)]/ gutsy main restricted
또는,
deb cdrom:[Debian GNU/Linux 4.0 r3 _Etch_ - Official i386 NETINST Binary-1 20080218-14:15]/ etch contrib main
라는 행이 있기 때문에 해당하는 행앞에 # 문자를 삽입해 주석처리 해주십시오.
#deb cdrom:[Ubuntu 7.10 _Gutsy Gibbon_ Japanese Remix - Release i386 (20071018)]/ gutsy main restricted
또는,
#deb cdrom:[Debian GNU/Linux 4.0 r3 _Etch_ - Official i386 NETINST Binary-1 20080218-14:15]/ etch contrib main
2.인스톨 작업을 다시한다.
방금전 중단 했던 인스톨 작업을 처음부터 다시 해 주십시오.
샘플 프로그램의 SimpleIO를 실행하는 run.sh을 실행할 수 없다.
run.sh에 실행비트가 설정되어 있지 않을 가능성이 있습니다. 이하와 같이 실행 비트를 설정하거나 직접 셸에 건네 실행해 주십시오.
> ls -al run.sh
-rw-r--r-- 1 n-ando n-ando 1146 4 27 15:12 run.sh
> chmod 755 run.sh
> ./run.sh
또는
> sh run.sh
샘플 프로그램 SimpleIO를 기동했지만 정상적으로 움직이지 않는다.
SimpleIO의 실행 스크립트 run.sh에서는 터미널 윈도우를 kterm，xterm，gnome-terminal중 어느 쪽인가에 가정하고 있습니다. 이 때문에, 이외의 터미널 윈도우를 사용하는 경우에는 run.sh을 적절히 고쳐 쓰고 나서 실행해 주십시오.
Cygwin을 인스톨하고 있는 환경에서는 python.exe가 복수 존재하는 경우가 있다.
Cygwin을 인스톨하고 있는 환경에서는 Cygwin상에서도 python.exe가 존재하는 경우가 있습니다. 그 경우는 일반적으로 Cygwin상의 python.exe에의 서치 경로가 우선되도록 설정되기 때문에 환경 변수 Path를 적절히 설정하고 있는데도 이번에 새로 설치한 Python과는 다른 버전의 （즉 Cygwin상의）python.exe가 기동되는 경우가 있습니다. 이 경우, Python의 버전의 다름에 의한 에러가 발생합니다. 이 문제는 매우 원인을 특정 하기 어려운 것이 특징입니다. 이와 같이 Cygwin등을 인스톨 하고 있는 환경에서 OpenRTM-aist Python버전을 사용하는 경우는 해당 버전의 python을 설치한 폴더에서 python.exe이 기동하고 있는 것을 확인해 주십시오.
확인 방법：
python -V 로 버전을 조사한다,（Cygwin이 있는 환경에서는）which python으로 어느 python.exe가 실행되고 있는지를 확인한다...등
이 에러가 발견되었을 경우의 대처：
Python인스톨 폴더(C:\Python26など)를 시스템 환경변수 Path（*유저 환경 변수 Path는 아님）의 앞부분에 추가하는 것으로 해결할 수 있습니다.
Python2.6+omniORBpy-3.4로 omniORB의 임포트시에 "ImportError: DLL load failed"에러가 발생한다.
mscr71.dll가 발견되지 않기 때문에 발생하는 에러입니다. msvcr71.dll를 여기에서 다운로드해 경로로 복사해 주십시오.
「MSVCP71.dll를 찾을 수 없기 때문에, …」라는 에러로 종료된다.
WINDOWS\system32폴더내에 msvcp71.dll가 없기 때문에 발생하는 에러입니다. msvcp71.dll를 여기 에서 다운로드해 주십시오.
「Can't open file: ./rtc.conf」등이라고 표시된다.
RT컴포넌트의 기동 폴더（또는 서치 패스상）에서 rtc.conf를 찾을 수 없기 때문에 기동할 수 없는 상태입니다. 이경우 다음과 같이 표시됩니다.
Can't open file: ./rtc.conf
Can't open file: /etc/rtc.conf
Can't open file: /etc/rtc/rtc.conf
Can't open file: /usr/local/etc/rtc.conf
Can't open file: /usr/local/etc/rtc/rtc.conf
이것은 rtc.conf를 찾는 서치 경로가 디폴트 상태이며, 위의 순서로 찾았지만 찾을수 없었기 때문에 이러한 메세지가 나옵니다. 이것을 피하기 위해서는, 예를들어
라는 내용의 파일 rtc.conf를 작성해 위의 서치 경로상（일반적으로는 현재 폴더＝컴포넌트와 같은 폴더）에 배치합니다.
컴포넌트가 네임 서비스에 등록되지 않는다.
rtc.conf의 개행 코드가 CRLF로 되어 있을 가능성이 있습니다.
이하의 커맨드로 rtc.conf의 확인을 해, CRLF라는 문자열이 표시되었을 경우 새로운 rtc.conf파일을 작성해 주십시오.
$ file rtc.conf
OpenRTM-aist(Java버전)
OS공통
Java버전 컴포넌트에 데이터 전송에 시간이 걸린다.
Java버전의 RT컴포넌트와 C++버전 등 다른 언어의 컴포넌트와의 사이에서, 특히 큰 데이터（100kB이상일 경우）를 송수신 하는 경우, 극단적으로 속도의 저하가 일어나는 경우가 있습니다. 이것은 Java의 CORBA측의 문제라는 것으로 알려져 있어 타임 아웃을 적절하게 설정하는 것으로 피할 수 있습니다.
Java버전의 RTC가 읽어 들이는 rtc.conf에 이하와 같이 기술하는 것으로 Java의 CORBA의 타임 아웃을 설정합니다.
corba.args: -ORBTCPReadTimeouts 1:60000:300:1
Java (JDK1.5이후) 에서는 디폴트로, 100:3000:300:20 라고 되어 있습니다만 이것을 1:60000:300:1 로 변경한다는 의미입니다. 각 항목은 왼쪽에서 부터,
CORBA 데이터를 read할 때에 0byte였을 경우 Read Thread 가 정지되는 시간(ms)
CORBA 데이터의 read시에 Read Thread가 대기하는 누적 최대 시간(ms)
GIOP의 헤더를 read할 때의 타임 아웃(ms)
CORBA 데이터를 read할 때에 Read Thread가 정지되었을 경우, 다음 정지 시간을 증가하는 비율(%)
라는 의미로 되어 있습니다. 따라서, 1:60000:300:1 는
read해서 0byte일때, Read Thread를 1ms정지한다.
Read Thread의 대기 최대 누적 시간은 6000ms
GIOP의 헤더를 read할 때의 타임 아웃 시간은 300ms
Read Thread의 정지 시간은 1%씩 증가시킨다.
라는 의미가 됩니다.
큰 데이터의 경우, 1회의 read로 데이터를 끝까지 읽을 수 없기 때문에 통상 몇회 read를 실시합니다.
다음 데이터는 빨리는 오지 않으므로 read는 읽어들인 바이트 수를 0byte로 돌아가지만, 통상 1ms이내에는 다음의 데이터가 옵니다. 디폴트의 설정이라면 Read Thread가 100ms 대기하지만 그렇게 장시간 기다릴 필요는 없고 1ms정도 기다리면, 곧 다음 데이터를 읽어들일 수 있습니다.
디폴트 설정의 경우, 100ms 기다리고 한번 더 읽어들이는 read가 0을 돌려주므로, 더 한층 100ms+20%의 120ms 대기합니다. 데이터가 너무 클 경우, 이것을 12회 반복하면 최대 누적 시간의 3000ms에 이르러 버리기 때문에 타임 아웃 하고, 데이터가 작아도 데이터의 분할수×100ms의 시간이 걸리기 때문에 매우 늦어집니다.
Java의 CORBA에서는 데이터를 100kB로 분할하기 때문에 이것을 넘는 데이터를 교환할 때, 위의 설정을 rtc.conf에 해두는 편이 좋습니다.
Windows
「java -version」가 인스톨 한 JDK 버전과 다르다.
이미 JDK보다 새 버전의 （Java Runtime Environment）가 인스톨 되어 있는 경우는, JDK를 인스톨 해도「java -version」가 JRE 그대로 되는 경우가 있습니다. 이 경우 인스톨의 확인 방법을 설명합니다.
「프로그램 제거 또는 변경」에서 확인방법
Windows의 제어판에서 「프로그램 제거 또는 변경」를 선택해, JDK5가 인스톨 되어 있는 것을 확인해 주십시오.
JDK5를 「프로그램 제거 또는 변경」에서 확인
내 컴퓨터에서의 확인 방법
JDK를 디폴트로 인스톨 했을 경우에는 통상
C:\Program Files\Java\jdk1.6.0_21
라는 경로에 인스톨되기 때문에 내 컴퓨터에서 직접 그 폴더의 존재를 확인합니다.
내 컴퓨터에서 JDK5를 확인
Unix
FedoraCore에서 Java를 인스톨한 경우의 대응
OS가 FedoraCore인 경우 yum에서 java를 인스톨 하면 GCJ(The GNU Compiler for Java )가 인스톨 되어, 그 GCJ를 사용하면 몇가지 에러가 발생가 발생합니다.
에러가 발생한 경우는 먼저, Sun Microsystems의 Java가 사용되고 있는지를 확인해 주십시오.
OpenRTM-aist(C++버전, Python버전, Java버전)에 관한 문제해결을 정리했습니다.
OpenRTM-aist(공통)
OS공통
컴포넌트는 분명히 기동되고 있는데도 좀비 오브젝트로 표시됩니다.
컴포넌트는 기동하고 있고 네임 서버에도 등록되어 있는데 RTSystemEditor의 네임 서비스 뷰 상에서는 좀비 오브젝트로 표시되고 있으며 시스템 에디터에 드래그 & 드롭해도 아무것도 표시가 되지 않습니다.[원인]컴포넌트를 기동한 호스트에 도달할 수 없음
RTSystemEditor가 동작하고 있는 PC로부터 컴포넌트를 기동한 호스트에 어떠한 이유로 도달 되어 있지 않을 가능성이 있습니다.먼저, RTSystemEditor가 기동하고 있는 PC에서 컴포넌트를 기동한 호스트에 대해서 ping이 도달하는가를 확인해 주십시오 예를 들어 이하의 3대의 호스트A, B, C가 있다고 가정합니다.
- hostA: 컴포넌트가 기동하고 있는 호스트
- hostB: 네임 서버가 기동하고 있는 호스트
- hostC: RTSystemEditor가 동작하는 호스트
이러한 호스트의 네트워크가 이하와 같이 구성되어 있어,[hostA]-(네트워크I)-[hostB]-(네트워크I)-[hostC]
한편 hostB가 네트워크I와 네트워크II사이를 적절하게 루팅 하도록 설정되어 있지 않으면 hostC에서 hostA에는 도달할 수 없습니다.
이러한 경우는 hostB를 적절히 설정해 hostC에서 hostA에 도달할 수 있도록 할 필요가 있습니다.
[원인]컴포넌트를 기동한 호스트에서 방화벽이 유효로 설정되어 있다.
컴포넌트가 동작하고 있는 호스트에서 방화벽이 동작하고 있는 경우, RTSystemEditor와 컴포넌트가 통신하지 못하고 이러한 현상이 발생하는 경우가 있습니다.방화벽의 설정을 재검토하거나 OFF로 하는 등 외부에서부터 컴포넌트의 통신이 가능하도록 해 주십시오.
Windows
인스톨러 실행중에 「…권한이 없습니다.」라고 표시되고 인스톨을 진행할 수 없습니다.
컴포넌트가 네임 서비스에 등록되지 않습니다.
네임 서버, 컴포넌트를 기동 후 RTSystemEditor등으로 네임 서버에 접속했을 때 컴포넌트가 등록되어 있지 않은 경우가 있습니다.이런 경우는
먼저 로그 레벨을 최고로 하기 위해 rtc.conf에
컴포넌트의 로그에
이러한 경우, 이하의 원인을 생각할 수 있습니다.
rtc.conf의 corba.nameservers가 올바르게 설정되어 있지 않다.
컴포넌트가 읽어들인 rtc.conf가 올바르게 설정되어 있는지를 확인해 주십시오. 이용하려고 하는 네임 서버를 openrtm.aist.go.jp라는 호스트 명으로 가정하면 이하의 행이 rtc.conf에 포함되어 있어야 합니다.
또, 네임 서버를 포트 번호를 지정해서 기동한 경우는 포트 번호도 지정할 필요가 있습니다. 네임 서버 기동시에 지정한 포트 번호가 1234번인 경우, 이하와 같이 설정할 필요가 있습니다.
컴포넌트를 기동한 호스트에서 네임 서버를 기동한 호스트에 네트워크 연결이 되지 않습니다.
컴포넌트를 기동한 호스트에서 네임 서버를 기동한 호스트에 네트워크 연결이 되는가 확인해 주십시오.먼저, ping이 도달하는지를 확인합니다. 만약 도달하지 않는다면 네트워크의 설정을 재설정해 주십시오.
ping이 도달해도 방화벽 등으로 연결이 금지되어 있는 가능성이 있습니다. 먼저 네임 서버를 기동한 호스트 측의 방화벽의 설정을 재설정해 주십시오. 가장 간단한 방법은 방화벽을 OFF로 하는 것입니다. 각 OS나 방화벽의 설정방법을 참조해 주십시오.
네트워크 인터페이스가 2개 이상 존재합니다.
호스트에 네트워크 인터페이스가 2개 이상 있는 경우, CORBA에 어느 쪽의 인터페이스를 사용할 것인지를 가르쳐 줄 필요가 있습니다.
이것은 네임 서버 측, 컴포넌트 측 모두 고려해야 합니다.
만약 각각의 호스트가 2개씩 인터페이스를 갖고 있고, 각 인터페이스의 어드레스가 이하와 같이 설정되어 있다고 가정합니다.(mask는 255.255.255.0라고 가정)
네임 서버host: eth0:192.168.0.1, eth1:192.168.100.1
컴포넌트host: eth0:192.168.0.2, eth1:192.168.11.96
이러한 경우 네임 서버host와 컴포넌트 host는 192.168.0의 네트워크에 연결되어 있을 것입니다.
따라서,
네임 서버에는 eth0:192.168.0.1
컴포넌트에는 eth0:192.168.0.2
의 인터페이스를 사요하도록 가르쳐 줄 필요가 있습니다.
네임 서버 측에서는 네임 서버를 기동할 때 OMNIORB_USEHOSTNAME라는 환경변수를 설정할 필요가 있습니다.
직접 rtm-naming (UNIX계) 혹은 rtm-naming.bat (Windows)에 써도 좋을 것입니다.
한편, 컴포넌트 측은 rtc.conf에 corba.endpoint의 설정을 기술하는 것으로 사용하는 인터페이스를 지정할 수 있습니다.
OpenRTM-aist(C++버전)
Windows
어플리케이션 에러「어플리케이션을 정상적으로 초기화하지 못했습니다.…」
OpenRTM-aist(C++버전)에서는 VC8（VS2005）를 베이스로한 것과 VC9（VS2008）를 베이스로 한 것이 있습니다. OpenRTM-aist-X.X.X-jp_vc8.msi（X.X.X은 버전)등의 VC8베이스의 인스톨러를 사용한 경우는 Microsoft Visual C++ 2005 SP1 재배포 가능 패키지(x86) 를、OpenRTM-aist-X.X.X-jp_vc9.msi（X.X.X은 버전)등의 VC9베이스의 인스톨러를 사용한 경우에는Microsoft Visual C++ 2008 재배포 가능 패키지 (x86) 를 인스톨해 주십시오.
「이 어플리케이션의 구성이 올바르지 않기 때문에 어플리케이션을 개시할 수 없습니다.…」
OpenRTM-aist(C++버전)에서는 VC8（VS2005）를 베이스로한 것과 VC9（VS2008）를 베이스로 한 것이 있습니다. OpenRTM-aist-X.X.X-jp_vc8.msi（X.X.X은 버전)등의 VC8베이스의 인스톨러를 사용한 경우는 Microsoft Visual C++ 2005 SP1 재배포 가능 패키지(x86) 를、OpenRTM-aist-X.X.X-jp_vc9.msi（X.X.X은 버전)등의 VC9베이스의 인스톨러를 사용한 경우에는Microsoft Visual C++ 2008 재배포 가능 패키지 (x86) 를 인스톨해 주십시오.
Visual C++ 2008 Express Edition에서 빌드 시 「'windows.h'르 찾을 수 없습니다.」라는 에러
Visual C++ 2008 Express Edition에서 빌드 시 다음과 같은 에러가 나오는 경우가 있습니다.
１．Microsoft Platform SDK가 인스톨되어 있지 않음
２．include 파일 경로・라이브러리 경로의 설정미비
- 대응방법：
- 인스톨하는 순서 등의 관계로 Visual C++ 2008 Express Edition의 설치 디렉토리와는 다른 장소에 にMicrosoft Platform SDK가 인스톨되는 이유로 인해 Visual C++ 2008 Express Edition의 컴파일러가 Microsoft Platform SDK의 include파일이나 라이브러리를 참조하지 못하는 경우가 있습니다. 이러한 경우는 include 파일 서치 경로나 라이브러리 서치 경로에 Microsoft Platform SDK의 인스톨 디렉토리를 추가하는 것으로 문제를 해결할 수 있습니다.
- include 파일 서치 경로의 추가 방법
- Visual C++ 2008 Express Edition의 메뉴바→「도구」→「옵션」을 선택해, 「옵션」윈도우를 엽니다. 왼쪽 트리뷰에서 「프로젝트 및 솔루션」→「VC++디렉터리」를 선택합니다.
- 라이브러리 서치 파일의 추가방법
- 위와 같은 방법으로「옵션」의 왼쪽 트리뷰에서「VC++디렉터리」를 선택한 상태에서, 우측상단의 풀다운 메뉴「다음 파일의 디렉터리 표시」를 「라이브러리 파일」로 하고 Microsoft Platform SDK의 라이브러리 파일의 디렉토리（예를들어, 「C:\Program Files\Microsoft Platform SDK\Lib」）을 라이브러리 파일의 서치 경로에 추가합니다.
또한 서치 경로의 구체적인 추가 방법 등은 Visual C++ 2008 Express Edition의 도움말 등을 참고해주십시오.오른쪽 상단의 풀다운 메뉴「다음 파일의 디렉터리 표시」를 「포함 파일」로 해서 Microsoft Platform SDK의 include 파일의 디렉토리（예를들어, 「C:\Program Files\Microsoft Platform SDK\Include」）를 include 파일의 서치 경로에 추가합니다.
rtm-naming의 실행에서 에러 발생
증상: rtm-naming.bat을 실행하면 어플리케이션 에러가 발생한다.VC++관련 라이브러리가 인스톨 되어 있지 않을 가능성이 있습니다.
VC++관련 라이브러리가 인스톨 되어 있지 않다.
Visual Studio 2008등의 어플리케이션이 인스톨되어 있지 않은 경우는 여기Visual Studio 2008 Express Edition에서 "Visual C++ 2008 Express Edition"을 다운로드해 인스톨 해주십시오.rtm-naming을 실행할 수 없다.
증상：rtm-naming.bat을 실행해도 검은 창（커맨드 프롬프트 화면）가 순간 열렸다 닫힙니다.[원인]omniORB가 인스톨 되어 있지 않다.
rtm-naming.bat내에서는 통상omniORB의 네임 서버 omniNames.exe를 실행합니ㅏ.omniORB가 인스톨 되어 있지 않으면 omniNames.exe도 인스톨 되지 않기 때문에, 네임 서버를 실행할 수 없습니다.
다운로드 페이지에서 omniORB를 다운로드해서 인스톨 해 주십시오.
[원인]log디렉토리의 경로 중에 2바이트 문자가 포함되어 있다.
rtm-naming.bat내에서는 통상omniORB의 네임 서버 omniNames.exe를 이해와 같이 실행합니다.
통상 환경 변수 %TEMP% 는 유저의 템프 디렉토리
대응방법으로 이하의 3가지 방법을 참고해 주십시오.
경로에 한글을 포함하지 않는 로그 디렉토리는 자신에게 작성할 수 있는 디렉토리로 안전한 위치로 해주십시오. 예를들어 C:\tmp 등.
이 네임 서버에는 omniNames과 같은 한글 경로의 문제는 존재하지 않기 때문에 이것을 사용하는 것으로 유저명이 한글이어도 네임 서버를 기동할 수 있습니다.
Unix
패키지의 자동 인스톨에서 다운로드 에러가 발생한다.
네트워크 접속이 정상인데도 다운로드 에러가 발생할 경우, 회선의 혼잡등으로 다운로드에 실패하는 경우가 있고 다운로드 사이트 측에서 파일의 위치나 이름을 변경했을 가능성도 있습니다. 전자의 경우는 시간대등을 늦추어 다시 자동 인스톨러를 실행해주십시오. 후자의 경우는, 해당하는 패키지를 찾아 각각을 다운로드해 수동 인스톨하던지 자동 인스톨러의 다운로드 원 주소를 수정하고 나서 다시 기동해주십시오
또한, 다운로드 사이트 측의 변경이 있을 경우 변경정보를 저희에게 연락을 해주시면 감사하겠습니다. 협력 부탁드리겠습니다.
configure를 실행했지만 에러가 발생해 종료한다.
make를 실행해도 빌드가 완료되지 않음. 또는 make 실행에러가 발생.
OpenRTM-aist의 인스톨에 실패한다.
이전 버전의 OpenRTM-aist이 완전히 삭제되지 않았을 경우, 새 버전을 인스톨 할 수 없습니다. 이전 버전을 완전히 삭제한 다음 다시 인스톨을 합니다.Vine・Fedora・ubuntu・debian공통：
pkg_install_XXXX.sh 을 이용해 삭제.
Vine：
apt-get명령어로 삭제합니다. 다음의 순서로 삭제해 주십시오.Fedora：
yum명령어로 삭제합니다. 다음의 순서로 삭제해 주십시오.ubuntu/debian：
apt-get명령어로 삭제합니다. 다음의 순서로 삭제해 주십시오.apt-get등을 사용해 인스톨 작업을 했을때 CD가 요구된다.
Ubuntu、Debian등의 디스크리뷰션에서 apt-get이나 pkg_install_ubuntu.sh, pkg_install_debian.sh을 사용해 인스톨 작없을 하고 있으면 다음과 같이 CD를 요구하는 경우가 있습니다. 미디어 변경:
물론, CD를 준비하면 좋겠지만 여러가지 사정에 의해 준비할 수 없는 경우의 처리 방법을 기술합니다.
이런 경우에는 우선, C-c(Ctrl+c)를 입력해 인스톨 작업을 중단하고 이하의 순서로 인스톨 작업을 다시해주십시오.
1./etc/apt/sources.list 을 편집
/etc/apt/sources.list 의 앞부분에
또는,
라는 행이 있기 때문에 해당하는 행앞에 # 문자를 삽입해 주석처리 해주십시오.
또는,
2.인스톨 작업을 다시한다.
방금전 중단 했던 인스톨 작업을 처음부터 다시 해 주십시오.샘플 프로그램의 SimpleIO를 실행하는 run.sh을 실행할 수 없다.
샘플 프로그램 SimpleIO를 기동했지만 정상적으로 움직이지 않는다.
SimpleIO의 실행 스크립트 run.sh에서는 터미널 윈도우를 kterm，xterm，gnome-terminal중 어느 쪽인가에 가정하고 있습니다. 이 때문에, 이외의 터미널 윈도우를 사용하는 경우에는 run.sh을 적절히 고쳐 쓰고 나서 실행해 주십시오.OpenRTM-aist(Python버전)
Windows
rtm-naming.py을 실행하면, omniNames가 "usage:"를 표시하고 종료된다.
증상
rtm-naming.py을 "C:\Documents and Settings\Hoge\My Documents"등 디렉토리 명에 공백이 들어가 있는 디렉토리에서 실행한 경우, omniNames는 "usage:"를 표시하고 종료합니다.대처 방법
이것은 rtm-naming.py의 버그에 의한 것입니다. 위의 증상이 나왔을 경우 아래의 방법으로 대처해 주십시오.python.exe이 기동하지 않는다.
Cygwin을 인스톨하고 있는 환경에서는 python.exe가 복수 존재하는 경우가 있다.
Python2.6+omniORBpy-3.4로 omniORB의 임포트시에 "ImportError: DLL load failed"에러가 발생한다.
「MSVCP71.dll를 찾을 수 없기 때문에, …」라는 에러로 종료된다.
「Can't open file: ./rtc.conf」등이라고 표시된다.
컴포넌트가 네임 서비스에 등록되지 않는다.
이하의 커맨드로 rtc.conf의 확인을 해, CRLF라는 문자열이 표시되었을 경우 새로운 rtc.conf파일을 작성해 주십시오.
OpenRTM-aist(Java버전)
OS공통
Java버전 컴포넌트에 데이터 전송에 시간이 걸린다.
Java버전의 RT컴포넌트와 C++버전 등 다른 언어의 컴포넌트와의 사이에서, 특히 큰 데이터（100kB이상일 경우）를 송수신 하는 경우, 극단적으로 속도의 저하가 일어나는 경우가 있습니다. 이것은 Java의 CORBA측의 문제라는 것으로 알려져 있어 타임 아웃을 적절하게 설정하는 것으로 피할 수 있습니다.Java버전의 RTC가 읽어 들이는 rtc.conf에 이하와 같이 기술하는 것으로 Java의 CORBA의 타임 아웃을 설정합니다.
- CORBA 데이터를 read할 때에 0byte였을 경우 Read Thread 가 정지되는 시간(ms)
- CORBA 데이터의 read시에 Read Thread가 대기하는 누적 최대 시간(ms)
- GIOP의 헤더를 read할 때의 타임 아웃(ms)
- CORBA 데이터를 read할 때에 Read Thread가 정지되었을 경우, 다음 정지 시간을 증가하는 비율(%)
라는 의미로 되어 있습니다. 따라서, 1:60000:300:1 는- read해서 0byte일때, Read Thread를 1ms정지한다.
- Read Thread의 대기 최대 누적 시간은 6000ms
- GIOP의 헤더를 read할 때의 타임 아웃 시간은 300ms
- Read Thread의 정지 시간은 1%씩 증가시킨다.
라는 의미가 됩니다.큰 데이터의 경우, 1회의 read로 데이터를 끝까지 읽을 수 없기 때문에 통상 몇회 read를 실시합니다.
다음 데이터는 빨리는 오지 않으므로 read는 읽어들인 바이트 수를 0byte로 돌아가지만, 통상 1ms이내에는 다음의 데이터가 옵니다. 디폴트의 설정이라면 Read Thread가 100ms 대기하지만 그렇게 장시간 기다릴 필요는 없고 1ms정도 기다리면, 곧 다음 데이터를 읽어들일 수 있습니다.
디폴트 설정의 경우, 100ms 기다리고 한번 더 읽어들이는 read가 0을 돌려주므로, 더 한층 100ms+20%의 120ms 대기합니다. 데이터가 너무 클 경우, 이것을 12회 반복하면 최대 누적 시간의 3000ms에 이르러 버리기 때문에 타임 아웃 하고, 데이터가 작아도 데이터의 분할수×100ms의 시간이 걸리기 때문에 매우 늦어집니다.
Java의 CORBA에서는 데이터를 100kB로 분할하기 때문에 이것을 넘는 데이터를 교환할 때, 위의 설정을 rtc.conf에 해두는 편이 좋습니다.
Windows
「java -version」가 인스톨 한 JDK 버전과 다르다.
Unix
FedoraCore에서 Java를 인스톨한 경우의 대응
에러가 발생한 경우는 먼저, Sun Microsystems의 Java가 사용되고 있는지를 확인해 주십시오.