DCSPC 시스템은 그리핑 제어를 위한 CDSP와 조립 알고리 즘, 로봇 제어기 통신 등을 담당하는 CARM으로 구분할 수 있 다. CARM은 범용 하드웨어 및 소프트웨어를 기반으로 개발 되기 때문에 임베디드 하드웨어 개발 필요성이 없다. 그러나 CDSP인 경우, 그리핑 모터를 위한 모듈, 그리핑 자세를 제어 하기 위한 컴플라이언스 모듈 등을 위한 하드웨어 개발이 필 요하며 실제 개발된 하드웨어는 [Fig. 1]과 같다. DCSPC의 하 드웨어는 [Fig. 1]과 같이 총 3개의 층으로 구성된다. 첫 번째 가장 하단에는 그리핑 모터 제어와 관련된 하드웨어와 전원 모듈이 이식되었다. 중간 계층에는 DSP 프로세서와 그와 관 련된 여러 하드웨어가 이식되었으며 부가적으로 디지털 I/O 와 CARM과의 통신 모듈이 함께 개발되었다. 마지막으로 가 장 상단에는 LVDT의 신호를 디지털로 변환하는 ADC 회로와 이후에 CARM 임베디드 보드가 장착되기 위한 주변 회로 등 이 구성되어 있다.

Fig. 1 

Hardware architecture of DCSPC

[Fig. 2]는 DCSPC 시스템의 이중으로 구성된 소프트웨어 구조도를 나타낸다. DCSPC는 모터 제어, 조립 알고리즘, 로봇 제어기 통신 등 정밀한 실시간 성능이 요하는 시스템이다. 이 를 위해 CDSP는 DSP의 하드웨어 타이머 인터럽트를 이용하 여 시스템 태스크가 실행되고, 하나의 태스크만으로 시스템 제어가 되므로 정밀한 실시간 성능을 만족하면서 동작되도록 설계하였다. 그러나 CARM 시스템은 범용 Linux를 이용하여 개발하였기 때문에 별도의 실시간 운영체제(Real-Time Operating System, RTOS) 이식이 필요하며 이는 아래에서 자세히 설명 한다.

Fig. 2 

Software architecture of DCSPC

[Fig. 2]의 좌측 소프트웨어 구조도는 CDSP의 전반적인 소 프트웨어 구조도를 나타낸다. CDSP는 3가지의 디바이스 드 라이버를 필요로 하는데 첫 번째로 그리핑 자세를 위한 LVDT 센서 인터페이스이다. LVDT 센서 모듈은 DSP에 설정된 주기 마다 호출되어 현재 LVDT 아날로그 값을 수신한다. 이 값은 외부 ADC칩과 DSP간에 SPI 통신을 이용하여 18bits 값을 수 신한다. 두 번째로 외부로부터 인가되는 명령어를 입력 받기 위한 시리얼 디바이스 드라이버이다. DSP 프로세서는 모터 제어, LVDT 송신, LED 제어 등의 명령어가 수신되면 즉시 최 우선인터럽트 핸들러가 호출되고 관련 명령어를 처리하게 된다.

마지막으로 그리핑 메커니즘을 구동과 관련된 DC 아날로 그 모터를 제어하기 위한 디바이스 드라이버이다. 모터 제어 알고리즘은 모터 위치 명령어가 입력되면 PID와 같은 선형제 어기를 통해 해당 모터 드라이버의 입력인 PWM 신호를 인가 하여 모터를 구동하게 된다. 예를 들어, [Fig. 3]은 위의 3가지 주요 기능이 1 ms 주기에서 실행되는 CDSP의 실행 예를 나타 낸다. DSP는 매 주기마다 현재 모터의 엔코더 값을 읽어온 후 PI제어를 통해 실시간으로 모터 제어 태스크를 처리한다. 만 약 CARM에서 LVDT 읽기 요청, 모터 제어 등의 명령어가 수 신되면 즉시 인터럽트를 이용하여 처리하며 그 외 시간에는 LVDT 센서에서 값을 업데이트 한다.

Fig. 3 

Execution sequence of CDSP

시스템은 기본적으로 Linux 범용 OS 기반으로 설계되었다. 범용 Linux는 Best-effort 방식의 태스크 스케줄링으로 처리되 므로 실시간 성능을 만족시킬 수 없다. 그러나 CARM 시스템 은 로봇 제어기와의 통신, 조립 알고리즘, CDSP와의 통신 등 실시간 성능이 매우 중요한 응용프로그램들이 동작된다. 따라 서 CARM의 실시간 성능 보장을 위해 Xenomai RTOS^[12] 소프 트웨어를 이용하여 시스템에 이식하였다. Xenomai RTOS는 오픈 소스를 이용하여 개발된 범용 리눅스 기반의 실시간 운 영체제로서 기존 Linux에서 가지는 실시간 성능의 한계를 Adeos 마이크로 커널을 이용하여 보장되도록 개발되었다. 범 용 Linux인 경우, Interrupt에 대한 우선순위 보장이 없으며. 태 스크 또는 프로세스에 대한 우선순위가 없기 때문에 정주기한 태스크 실행을 보장 받지 못한다. 이에 반해 Xenomai 태스크 는 태스크 설정 시, 우선순위, 주기 등에 대한 정보 설정이 가 능하며 이를 위해 실시간 스케줄링 또한 지원을 하고 있다.

CDSP는 CARM 시스템과 SCI (Serial Communications Interface) 이용하여 통신을 수행하며 기본적으로 슬레이브의 역할로 개 발되었다. 3.2절에서 제시한 것과 같이 CDSP는 CARM 시스 템에서 LVDT 읽기, 모터 제어, I/O 모듈 제어 등의 외부로부 터의 요청이 수신될 수 있다. 또한 [Fig. 2]에서 제시한 것과 CARM은 외부 로봇 제어기와의 통신 인터페이스를 제공한다. 전통적인 그리퍼 제어 시스템은 로봇 축 가장 말단에 부착되 어 제어되는 방식으로 동작되었다. 그러나 본 논문에서는 조 립 정밀도를 높이고 실시간으로 그리퍼 제어를 하기 위해 외 부 로봇 제어기와 통신하기 위한 명령어를 개발하였다. [Table 1]은 현재 CDSP, CARM에서 제공되는 모든 API를 제시한다.

CARM 시스템은 외부 로봇 제어기 및 CDSP의 DSP 프로세 서 사이에 물리적인 인터페이스로 연결되어 통신을 수행한다. 그 중 외부 로봇 제어기와는 로봇의 현재 위치 읽기 명령어 (RC_GetCurrX), 로봇 이동 명령어(RC_MoveX), Job Point 읽 기(RC_GetJobPointX) 및 쓰기(RC_SetJobPointX)명령어와 정 수 변수 읽기 명령어(RC_GetInteger)를 통해 통신한다. 이때 X 인덱스는 로봇 관절 단위(Joint, J)와 직각 좌표계 단위 (Cartesian, C)로 구분된다. 여기서 Job의 개념은 로봇의 공정 을 하나의 집합을 의미하며 한 개의 Job은 복수의 JobPoint(이 하 JP)로 구성된다. 이때 로봇 관절 단위 일 때 JobPoint요소는 JPjp=[J1, J2 ⋯, J6], 직각 좌표일 때 JobPoint 요소는 JPjp=[x, y, z, θz, θy, θz]의 형태로 최종적으로 정의된다. Job에 대 한 예는 [Fig. 4]와 같다. 여기서 JP_jp의 아래 첨자 jp는 Job번호 j와 JobPoint 번호 p로 정의될 수 있다. 즉 하나의 경로 j에 대해 임의의 개수만큼 JobPoint를 구성하여 p로 구성 되며 이에 대 한 정보는 로봇 제어기에 저장되어 관리된다.

Fig. 4 

Example of two job trajectory

본 논문에서는 DCSPC 시스템의 유효성 검증을 위해 Denso, UR, Robostar 등의 로봇 제어기를 채택하였다. 그러나 로봇 제어기와 CARM 프로세서 사이에 공유 변수가 정의되고 사용될 수 있어야 하는데 UNIVERSAL ROBOTS社는 이에 대 한 기능을 현재 제공하지 않고 있다. 따라서 본 논문에서는 이 를 지원하기 위해 UR 로봇 제어기에 별도의 TCP/IP 소켓 통신 을 할 수 있는 UR 스크립트 소켓 프로그램을 개발하였으며 이 에 대한 내용은 [Fig. 5]와 같다. 스크립트 소켓 프로그램은 시 스템 초기에 UR 제어기에서 실행되고 필요한 전역변수를 선 언한다. 그 이후 지속적으로 CARM의 전역변수 읽기 및 쓰기 명령어 수신 여부를 검사하며 해당 시점에 즉시 처리하게 된 다. 위의 추가 기능으로 2개의 제조사와 다르게 TCP/IP 소켓 통신의 이중 구조로 인한 시스템 오버헤드가 가장 취약함을 알 수 있어 본 논문에서는 UR 로봇 제어기를 채택하여 실험 및 검증을 진행하였다.

Fig. 5 

Socket communication of w.r.t. robot in UR (ex. RC_GetJobPointC)

본 논문에서 제안하는 DCSPC의 CARM은 상용 임베디드 보드를 이용하여 개발하였기 때문에 실시간 검증이 매우 중요 하다. CARM은 CDSP와 외부 로봇 제어기와의 통신을 처리하 기 때문에 정주기성이 엄격하게 지켜져야 하며 따라서 본 절 에서는 Beagle bone black의 정주기성 성능 평가를 진행하였 다. 실험을 위해 Xenomai Task 주기는 500 μs와 1 ms로 설정 하였으며 총 60,000개의 샘플링 데이터를 취득하였고 그 결 과는 [Fig. 7]과 같다. 그 결과, 주기가 1 ms에는 999999.92(ns) 평균 주기와 765.64(ns)의 편차를 보였으며 500 μs일 때 499999.91(ns) 평균 주기와 편차 560.71(ns)가 측정되었으며 매우 정밀한 정주기성을 확인할 수 있었다.

Fig. 7 

Experiment result of task period (1 ms period (up) / 500 μs period (down))

[Table 1]에서 제시한 API에 대한 통신 시간 측정은 시스템 제어 주기를 결정하기 위한 실험이다. 본 절에서는 CDSP 및 CDSP 통신 간에 사용되는 LVDT_Function, DIO_Function, 그 리고 MC_Function 실험을 진행하였다. 두 시스템간의 SCI 통 신 속도는 1.875 Mbps이며 3분 시간 간격으로 1회에 3개의 데 이터를 취득, 총 30개의 데이터를 취득하였다. 첫 번째로 LVDT_Function 명령어는 CARM에서 4 byte 요청 메시지를 송신하고 CDSP는 즉시 52 byte의 응답 메시지를 송신하다. 위 와 동일한 방법으로 DIO_Function은 5 byte 요청 메시지와 4 byte 응답 메시지, 그리고 MC_Function은 20 byte의 요청 메시 지와 4 byte의 응답 메시지를 서로 교환한다. 실험 결과, 3개의 API는 순차적으로 평균 312.66 μs, 53.75 μs, 137.21 μs 통신 시 간이 소요되었으며 [Fig. 8]과 같다. 전체 통신 시간은 요청 응 답 메시지의 크기와 통신 속도에 의존적임을 알 수 있다. 실제 로 3개의 API를 처리하기 위한 DSP 처리 시간은 평균 4.44 μs, 5.71 μs와 2.47 μs 시간만이 소요되어 전체 실행시간에서 큰 비 중을 차지하지 않음을 확인하였다.

Fig. 8 

Communication time of CDSP and CARM

3.3절 [Table 1]의 API에서 CARM와 외부 로봇 제어기의 통 신에 소요되는 시간을 측정하였다. 외부 로봇 제어기와 통신 하는 명령어 중 이중 TCP/IP 소켓 통신을 필요로 하는 5개의 함수의 오버헤드가 더 높기 때문에 5개의 함수 실험 결과를 [Fig. 9]에 나타내었다. 현재 위치 읽기 및 로봇 구동 명령어 실 험은 약 10,000개의 데이터 취득 결과 99% 이상 1 ms미만의 통 신 시간이 측정되었다. 그러나 5개의 API인 경우 평균 6.15 ms 와 2.44 ms의 편차를 보였다. 이는 UR3 로봇인 경우, 이중 TCP/IP 구조가 많은 시스템 오버헤드를 증가시킴을 알 수 있 었으며 추후 시스템 개선의 여지가 있음을 확인하였다.

Fig. 9 

Communication time of CARM and external robot controller (unit: nanosecond)

본 절에서는 가상의 조립 작업을 수행하는 태스크를 수행 되었을 때 DCSPC의 시스템 오버헤드를 측정하였다. 로봇은 임의의 두 지점을 왕복 운동하는 모션을 수행하는데 이때 이 동 지점, 모션 시작 및 종료 명령은 CARM에 의해 요청되어 수 행된다. 임의의 두 지점에서 CDSP는 가상의 제품을 조립하기 위해 특정 시간 동안 모터 구동을 수행 후 종료하게 된다. 위의 전체 동작을 수행하는 동안 CARM은 CDSP에 주기적으로 LVDT 값을 요청하여 지속적으로 현재 DCSPC의 위치를 모니 터링을 수행한다. 위의 가상 조립 작업을 30회 수행하였으며 4 회를 걸쳐 총 120회의 작업을 수행하였다. 실험결과, 각각의 작업 수행 시간은 1 ms이하의 적은 오차로 약 76초가 측정되 었으며, 동일 시간으로 반복 작업이 수행됨을 확인할 수 있었다.