Ⅳ. 산학협력 성과
2. 참여기업 만족도
연구개발 성과
가. 인프라 구축 (H/W, S/W)
1) 개발환경 구축을 위한 H/W구성
- Robotis, Robobuiler, Dongburobot 세 개 로봇 제조사 선정 및 엑츄에이터 구입.
- 임베디드 보드 선정( I.MX53 Quick Start Board, I.MX6 NitrogenX )
2) S/W 체계 설계
- 각 제조사 별 프로토콜 수집 및 데이터 쉬트 확보
- ubuntu OS, kernel, device driver, real timer source 데이터 확보 - USB 포트, LAN, VGA 포트 확인.
- USB to RS232, USB to RS485 구입 및 테스트.
나. 실시간 소프트웨어 개발환경 구축
1) 커널 환경 및 드라이버 환경 구축
- 크로스 컴파일을 위한 컴파일러 설치 완료 - kernel version : 2.6.35
- 임베디드 시스템 설치에 따른 방법을 매뉴얼화
- USB to Serial 프로그램 제작 및 테스트(FTDI사 USB to Serial Driver 컴파일 및 예제 테스트)
2) Tool 선정 및 단위 예제 프로그램 구동
- QT 4.6 설치 및 확인 완료- 단위 예제 프로그램 실행
다. 모듈라 엑츄에이터 제어 프로그래밍
1) 엑츄에이터 구동 및 제어
- 각 제조사 별로 프로토콜 분석(robotis, robobuilder, dongbu robot) - 엑츄에이터 실제 구동 및 테스트 완료
2) 2개사 이상의 제품으로 라이브러리 구축
- 엑츄에이터 필요한 구문을 함수화
○ 데이터 송신 : 위치, 속도, 가속도, 토크 ○ 데이터 수신 : 위치, 속도, 가속도, 토크 - 엑츄에이터 싱글 통신과 멀티 통신으로 분할
라. 영상처리 프로그래밍
1) 영상 프로그래밍
- I.MX53 QSB에서 영상 송신 프로그램 제작 및 테스트 - 특정 색을 지정해 위치 파악 프로그램 제작 및 테스트
마. 영상처리 프로그래밍
1) 로봇에 적합한 체계 구축 및 표현
- TCP/IP 통신 프로그램 제작 (임베디드 보드 - PC)
- TCP/IP 통신 프로그램 제작 (임베디드 보드 - 스마트기기) - RS232 to RS232, RS485 PCB 개발 완료(open-collector 방식) - 참여기업과 프로토콜 정의 및 협의 완료
- 프로토콜에 맞춰 예제 프로그램 제작 및 테스트 ○ 로보티즈 : 델타 봇
○ 로보빌더 : 휴머노이드 로봇(웹캠 영상 송신) ○ 동부로봇 : 휴머노이드 로봇
2. 기술적 우수성
o 기술적 측면
- 현재 로봇 시장에서 판매되고 있는 엑츄에이터에 대해 명령 단일화 - 신소재, 반도체, 인공지능 등 첨단 기술의 적용과 융합 가능
- 예술작품 제작 시 소형 엑츄에이터가 필요한 경우 이공계 지식이 없는 예술인들에게 접 근하기가 용이.
o 산업적 측면
- 소프트웨어 및 컨텐츠 업체도 솔루션을 소비자에게 제시함으로써 건전한 경쟁이 가능 - 로봇 전문 강사의 학습장벽을 낮춤.
- 다양한 교육산업으로의 공급 확대 가능 - 새로운 응용분야 창출을 통한 신규시장 확보
- 국가적 사업과의 연계 서비스 발굴을 통해 전후방 산업으로 부가가치 확대 가능 - 교육 IT화에 소요되는 비용 절감
- 로봇 산업 육성과 글로벌 시장 선도 및 국가 산업경쟁력 강화 - 신 비즈니스 모델 창출 및 융합을 통한 산업역량 극대화 - 지역경제 활성화 및 글로벌 변화 대응
- 융합 및 ECO 산업을 선도하여 성장 가속화
스마트 기기 연동 모듈형 엑츄에이터 로봇 제어를 위한 임베디드 소프트웨어 개발
구분 내용
개발기술 및 개발내용
1. 인프라 구축 및 H/W 구성
- 개발된 시스템은 사용자가 제조사에 상관없이 스마트 엑츄에이터를 제어하는 데 중점을 두고 제작되었다.
- 스마트 기기와 임베디드 보드는 통신이 가능하며 서로 영상을 송/수신할 수 있다.
- 임베디드 보드는 linux 배포판 ubuntu 10.04가 설치되어 있고 사용자가 자체적으로 프로그램을 수정할 수 있다.
<그림1-1> 시스템 구조
- 본 시스템의 개발 환경은 아래와 같다.
[표1-1]시스템 개발환경
구분 제원
- 크로스 컴파일용 PC
° CPU : Intel(R) I5-4880 core
° memory : 4GB
° OS : Linux 배포판 Ubuntu 12.04
° Development tool : QT Creator
° 저장장치 : Samsung SSD 128GB - Logitech WebCam C905
° linux 호환가능
° 해상도 : 최대 1600×1200
° 초당 최대 30프래임 출력
° USB 2.0지원 - USB to Serial
° 최대 1Mbps
° RS232 통신 방식
2. 인터페이스 보드 개발
- 스마트 엑츄에이터는 <그림 2-1>과 같은 멀티드롭방식을 사용한다.
<그림 2-1> 멀티드롭
° 장점 : 엑츄에이터간의 통신연결이 간편하다.
° 단점 : 1:N 통신에서 소모되는 전류가 연결된 엑츄에이터에 비례한다.
- 시중에서 판매되고 있는 USB to RS232 장치는 최대 전류가 30mA로 제한된다.
따라서 다수의 엑츄에이터를 제어하기에는 추가적인 회로 설계가 필요했다.
- I.MX53 Quick Start Board
° 1GB DDR3 memory
° LVDS support
° I.MX53 1GHz ARM Cortex-a* Processor
° VGA support
° MC34708 PMIC
- 동부로봇 엑츄에이터
° DRS-020X series
° DRS-040X series
- 로보티즈 엑츄에이터
° AX-12 Series
° MX-106 Series
- 로보빌더 엑츄에이터
° SAM-28 Series
- 위에서 제시한 문제를 전류 공급방식 을 open-collecotr 로 설계했다. 제시한 방식으로 사용하면 여러 장점이 있다.
° 통신 전압 레벨을 자유롭게 바꿀 수 있다.
° 멀티 드롭 방식을 사용할 때 전류 제 한 문제가 해결된다.
<그림 2-2> open-collector 방식
- <그림 1-4>는 open-collector 방식으로 설계된 인터페이스 보드이다.
<그림 2-3> 인터페이스 보드
- 통신 전압레벨을 5V와 3.3V로 사용자가 선택할 수 있게 설계했다.
- RS232 to RS232, RS232 to RS485 두 가지방식을 사용자가 선택할 수 있게 설계 했다.
3. 개발 환경 구축
- 임베디드 보드(Target board)에서 프로그래밍과 디버깅을 동시에 하기에 성능상 제약이 따른다. 따라서 Host PC를 크로스 플랫폼으로 구축하고 프로그래밍과 디 버깅을 했다.
- Target board : I.MX53 Quick Start Board(이하 I.MX53 QSB) - Host PC : Ubuntu 12.04
- development tool : QT Creator, LTIB
<그림 3-1> 크로스 플랫폼 시스템 구조
- <그림 3-1>은 본 사업에 개발 환경을 나타낸 것이다.
- 개발환경 구축 내용과 방법에 대한 부분은 문서로 남겨놓았다.
<그림 3-2> 개발환경 매뉴얼화
- 증빙자료로 아래 문서들을 첨부한다.
○ I.MX53_LTIB_Build
○ I.MX53_Ubuntu_QT
○ I.MX53_User_Guide
4. S/W
1) S/W 구성도
<그림 4-1> 소프트웨어 구성도
- 사각박스는 디바이스를 나타내며 동그라미는 디바이스 내부 소프트웨어를 의미한 다. app은 스마트 디바이스 내부에서 Wi-Fi, Serial, Video는 임베디드 보드 내부에 서 작동중인 프로세스를 의미한다. 이들 각각의 역할은 아래와 같다.
° app : 스마트 디바이스 내부에서 작동중인 프로세스로서 사용자가 터치 버튼이 나, 스크롤 바를 이용해서 임베디드 보드에 데이터를 전송하게 되어있다. 사용자가 입력한 데이터는 정의해둔 프로토콜을 따른다.
° Wi-Fi : 스마트 디바이스와 임베디드 보드간의 통신 프로토콜 파싱 및 Serial, Video 프로세스에게 명령 및 응답을 담당한다.
° Serial : Wi-Fi 프로세스에서 받은 명령을 엑츄에이터에 맞는 프로토콜로 변경 및 명령 전송을 담당한다.
° Video : 웹캠과 통신 및 Wi-Fi 프로세스에게 영상을 전송한다.
- 스마트 디바이스 내부에서 작동중인 어플리케이션은 사용자가 개발하는 것으로 서 <그림 4-2>는 본 시스템 개발에 시험적으로 제작한 어플리케이션이다.
<그림 4-2> 테스트 어플리케이션
2) 엑츄에이터 제어
<그림 4-3> 엑츄에이터 제어 프로세스 구성
- 스마트기기에서 엑츄에이터를 제어하기 위해 <그림 4-3>과 같은 프로세스를 실 행한다. 어플리케이션에서 Wi-Fi 프로세스에 명령을 주고 Wi-Fi 프로세스에서 패 킷을 해석해 Serial 프로세스에게 명령을 전달한다. Serial 프로세스는 받은 명령어 를 전달할 엑츄에이터의 제조사, 모델명, 정규화된 데이터값을 패킷으로 만들어 엑 츄에이터에게 명령을 내리게 된다.
- 이에 따라 각기 다른 제조사의 프로토콜을 통합해야 한다.
➀ 스마트 엑츄에이터 통합 제어 라이브러리 개발
<그림 4-4> 임베디드 보드와 엑츄에이터간 통신
초기화 Dongbu_Init Robobuilder_Init Robotis_Init 위치제어 Dongbu_WrPos Robobuilder_WrPos Robotis_WrPos 속도제어 Dongbu_WrVel Robobuilder_WrVel Robotis_WrVel 가속도제어 Dongbu_WrAcc Robobuilder_WrAcc Robotis_WrAcc 토크제어 Dongbu_WrTor Robobuilder_WrTor Robotis_WrTor 위치값 읽기 Dongbu_RdPos Robobuilder_RdPos Robotis_RdPos 속도값 읽기 Dongbu_RdVel Robobuilder_RdVel Robotis_RdVel 가속도값 읽기 Dongbu_RdAcc Robobuilder_RdAcc Robotis_RdAcc 트크값 읽기 Dongbu_RdTor Robobuilder_RdTor Robotis_RdTor
° 초기화 : 엑츄에이터의 번호, 통신속도 변경
° 위치제어 : 엑츄에이터의 현재 가리키고 있는 방향 변경
° 속도제어 : 엑츄에이터의 현재 회전 속도 변경
° 가속도 제어 : 엑츄에이터의 현재 회전 가속도 변경
° 토크 제어 : 엑츄에이터의 현재 최대 토크값 변경
➁ 디바이스간 프로토콜
0x0AReq Res 0x0B
° 초기화
- 초기화는 스마트 기기에서 임베디드 명령을 내리고 스마트 엑츄에이터에게 리턴
- <그림4-9>과 같이 모터 상태요청을 하면 임베디드 보드에서 지정된 ID의 엑츄에
- 모터 설정값은 사용자 입장에서 값이므로 임베디드 보드에서 엑츄에이터에 맞게
B. 응답
B. 응답
B. 응답
- 임베디드 보드 내에 본 시스템이 시작할 때 WebCam 디바이스의 초기화를 시작 한다. 초기화 내용은 다음과 같다.
° 메모리 메핑(버퍼 사이즈, 주소 공간 할당)
° 영상 데이터의 높이와 너비
° 영상 데이터 유형(MPEG, BMP, YUV...)
° 영상 데이터 출력 방식(스트림, 캡쳐...)
° 영상 데이터 초당 프레임 수
- <그림 4-14> 은 웹캠 디바이스 초기화과정을 도식화한 것이다. 사용자가 지원이 안되는 데이터를 입력했을 시 시스템이 다음 과정으로 넘어가지 않는 상태를 방지 하기 위해서 웹캠 디바이스에서 사용자가 입력한 값의 최대한 가까운 값을 갱신해 서 재요청을 시작해서 초기화를 마무리 한다.
- 임베디드 보드에서 영상 데이터를 받아오기 위해서 V4L2 라이브러리를 이용했 다. V4L2라이브러리는 리눅스에서 영상 데이터 처리를 위한 라이브러리이며 본 시 스템에 성능면(영상 출력 속도, 영상 데이터 유형,...)에서 적합하다.
- <그림4-15>에서 프레임 버퍼는 실제 웹캠에서 받아온 영상이 임시적으로 저장되 는 공간을 의미한다. 즉, 메모리 메핑으로 설정해둔 버퍼이다.
- 허프만 공식은 YUV를 BMP포멧으로 바꿔주는 함수에 들어가는 알고리즘이다.
YUV포멧을 BMP포멧으로 바꾸는 작업은 CPU에 상당한 자원이 투자되야 하기 때 문에 스마트기기 코어에 부하를 줄이기 위해서 임베디드 보드 내부에서 처리한다.
- 임베디드 보드에서 영상 처리는 프로세스로 작동되며 <그림4-16>과 같은 위젯으 로 테스트 결과 초당 20프레임으로 확인했다.
<그림4-14> 웹캠 초기화 알고리즘 순서도
- 실험은 영상 사이즈 640×480, YUV 포맷으로 했으며 1초 동안 프레임 버퍼를 카 운트해서 측정 했다.
<그림 4-16> I.MX53 QSB에서 영상 출력
➁ 스마트기기와 임베디드 보드간 통신
- 스마트기기와 임베디드 보드는 Wi-Fi를 이용해서 서로 통신을 주고받는다. 이 때 사용되는 프로토콜은 UDP/IP, TCP/IP 둘 다 가능하다.
- 명령은 TCP/IP를 사용하고 영상 전송에 있어서는 UDP/IP를 사용한다.
- 영상 출력에 대한 프로토콜 전문은 아래와 같다.
<그림 4-15> 영상 요청 알고리즘 순서도
- 웹캠에서 임베디드 보드로 영상을 받고 그 영상을 스마트 디바이스에서 처리하
- 웹캠에서 임베디드 보드로 영상을 받고 그 영상을 스마트 디바이스에서 처리하