마우스 포인터는 어떻게 캡처할까??? :: 2009/07/01 06:29 by 우종하(19기)
자동 동영상 편집 기능을 갖춘 강의녹화 프로그램 개발 프로젝트 진행중에
윈도우 데스크탑 녹화 모듈에서 마우스 포인터를 비트멥에 추가할 수 없는 문제를 처음에 봉착했었습니다.
기억하시죠? 아래아래(...계속 아래...)글 보시면~(참고하시고...^^;)
벌써 한두달 전의 일이라 가물거리는 기억을 꺼내 이렇게 또 기록해 두려 합니다.
자 그럼 간단명료하게 가볼까요? 그럼 소스 먼저 보겠습니다.
이 코드만 생성해 놓은 비트맵에 추가 해주신다면 마우스 포인터까지 녹화가 가능합니다. 간단하죠?
그럼 간단히 소스를 설명하자면....CURSORINFO를 GetCursorInfo() 를 통해 받아와서 커서가 존재하면 커서 좌표를 계산해서 DC에 커서를 그려 넣으면 되겠습니다.
여기서 중요한거 딱 두가지~!
첫 번째! CURSORINFO 의 cbSize를 CURSORINFO의 size로 설정해야한다는 것! 이 코드만 없어도 제대로 동작 하지 않더군요 ^^;
두 번째! 커서도 아이콘 이라는 것~! CopyIcon(), DrawIcon()을 사용 한다는 것 잊지 마세요~~!
정말정말 간단하죠? 너무 짧게 블로깅을 하는 것 같아서.........손이 부끄럽지만... 아마도 스크린 녹화 모듈 개발 작업에서 빼놓을 수 없는 아주 중요한 코드라 생각되어 공개 합니다...! 유용하게 쓰세요~~ㅇ
Remote Desktop Protocol for Win32 :: 2009/07/01 01:10 by 이도광(19기)
App-Hand(Application In My Hands)
App-Hand Project에서 가장 중요한 부분중에 하나인, Remote Desktop Protocol에 대한 이야기 입니다.
먼저, 사용자는 자신의 컴퓨터에 별도의 애플리케이션을 설치하고 않고서, 서버(Windows Server 2003)에 애플리케이션을 설치해둔 뒤, 사용자는 서버에게 서비스를 받는데 이를 위해 Remote Desktop Protocol을 사용하여야 합니다. Microsoft에서 Remote Desktop Protocol(이하 RDP)을 제공하기는 하지만, 우리 프로젝트의 특성상 소스코드가 필요하였고, MS에서는 이에 대한 소스코드를 공개하지 않았기 때문에 우리는 이에 따른 RDP가 필요하게 되었습니다.
따라서 RDP에 대한 정보를 단 한곳에서만 제공하는데 이는 www.rdesktop.org에서 제공합니다.
예전 MS에서 터미널 서비스 개발자였던 사람이 만든 Org라고 하더군요.
따라서 우리는 이 프로토콜을 분석 및 포팅하여 Windows Version으로 재구축 하기로 하였습니다.
RDP / SECURE / MSC / ISO / TCP
이렇게 다섯 계층으로 RDP는 이루어져 있습니다.
터미널 서비스 역시 3389 포트로, TCP Connection으로 이루어져 있습니다.
그리하여 RDP는 마우스 및 키보드 메시지가 발생되면 그에 따른 정보를 Server에게 보내줍니다.
소스로는 아래와 같습니다.
static LRESULT CALLBACK WndProc(
HWND hwnd, // handle to window
UINT uMsg, // message identifier
WPARAM wParam, // first message parameter
LPARAM lParam) // second message parameter
{
PAINTSTRUCT ps;
HDC hdcPaint;
switch (uMsg)
{
case WM_PAINT:
hdcPaint = BeginPaint(hwnd, &ps);
if (!BitBlt (hdcPaint,
ps.rcPaint.left,
ps.rcPaint.top,
ps.rcPaint.right - ps.rcPaint.left,
ps.rcPaint.bottom - ps.rcPaint.top,
hdc,
ps.rcPaint.left,
ps.rcPaint.top,
SRCCOPY))
error ("bitblt failed\n");
EndPaint(hwnd, &ps);
break;
case WM_KEYDOWN:
rdp_send_input(time (NULL), RDP_INPUT_SCANCODE, RDP_KEYPRESS, (lParam & 0x00FF0000) >> 16, 0);
break;
case WM_KEYUP:
rdp_send_input(time (NULL), RDP_INPUT_SCANCODE, RDP_KEYRELEASE, (lParam & 0x00FF0000) >> 16, 0);
break;
case WM_LBUTTONDOWN:
rdp_send_input(time(NULL), RDP_INPUT_MOUSE,
MOUSE_FLAG_BUTTON1 | MOUSE_FLAG_DOWN, GET_X_LPARAM(lParam), GET_Y_LPARAM(lParam));
이렇게 사용자의 메시지를 서버에게 보내게 되는 방식으로 진행되게 됩니다.
이렇게 보낸 메시지 기반으로 서버는 사용자 단위로 가상채널(Virtual Channel)이 생성되는데, 해당 채널에게 메시지를 보내게 됩니다. 그럼 사용자의 핸들링에 따라 해당 서버측에 띄워져 있는 프로세스들이 이벤트를 발생시키게 되며 이에 대한 무효화 영역이 발생되면 클라이언트에게 해당 좌표 및 비트맵을 사용자에게 보냅니다.
사용자는 이를 Parsing하여 모니터에 뿌려주게 되는 방식입니다.
switch (os->order_type)
{
case RDP_ORDER_DESTBLT:
process_destblt(s, &os->destblt, present, delta);
break;
case RDP_ORDER_PATBLT:
process_patblt(s, &os->patblt, present, delta);
break;
case RDP_ORDER_SCREENBLT:
process_screenblt(s, &os->screenblt, present, delta);
break;
case RDP_ORDER_LINE:
process_line(s, &os->line, present, delta);
break;
case RDP_ORDER_RECT:
process_rect(s, &os->rect, present, delta);
위 소스와 같이 서버로부터 무효화 영역에 따른 메시지를 수신하게 되면 클라이언트를 이를 파싱하여
해당 작업 프로시저로 향하게 되는데, 이때 파라미터로 넘기는게 바로 "s"라는 파라미터!
"s" 파라미터에는 클라이언트 모니터에 뿌려주게 될 X, Y 좌표 등 필요한 좌표정보들이 들어있습니다.
이를 근거로 모니터로 뿌려주게 되는 형식입니다.
지자기 센서값을 이용한 Heading측정 :: 2009/06/30 21:59 by 손영태(17기)
기체의 Z축 방향(heading or Yaw)을 절대값으로 구하기 위해 지자기센서와 가속도센서 성분을 이용하여 구했다. 지자기센서의 Magnetic Field(지구 자장)를 이용하여 Z축의 회전방향을 값을 구하는데 이때 지구의 수평방향과 기울어질 경우 자기장의 값이 달라지기 때문에 가속도 센서를 이용하여 구해진 X축(Roll), Y축(Pitch)의 회전각을 이용하여 기울어진 자장의 값을 보정하였다. 1 차적으로 Roll angle값과 Pitch angle값은 Rotation Matrix를 이용하여 구해지고 그결과는 Roll(ф), Pitch(θ)로 구해진다. 이 벡터 성분에 지자기 센서에서 측정 3방향의 지구 자장값을 사용하여 Heading 성분을 구한다.
Matlab을 이용한 버터워스 필터의 계수 구하는 방법 :: 2009/06/30 21:09 by 19기 정현철
Butterworth Filter Design by Matlab
“UAV“ 센서부에서 나오는 신호의 잡음을 제거하기 위한 디지털 필터의 계수를 Matlab을 통해 구하는 방법을 구성해 보았습니다. 결과 값이 다시 입력의 성분으로 들어가는 IIR 필터 이며, 특성은 평탄한 주파수 응답을 가지는 Butterworth입니다.
>> fs=320; Sampling frequency of signal [Hz=1/sec}
>> fn=fs/2; Nyquist frequency
>> Ts=1/fs; Sampling period [sec]
Filter Order Calculation
>> [n, Wn]=buttord(30/fn, 45/fn, 1, 12) 30/fn: passband cutoff frequency (30Hz)
45/fn: stopband corner frequency (45Hz)
1: passband ripple in decibels
12: stopband attenuation in decibels
>> n
n= 6
>> Wn
Wn=0. 3dB frequency 0. …X fn= Hz
Filter Coefficient Calculation
>> [b, a]=butter(n, Wn) Filter coefficient calculation
아래는 실제 Matlab 에서 구해 보았습니다.
fs = 320
fn = fs/2
ts = 1/fs
ts = 0.0031
[n,wn]=buttord(30/fn,45/fn,1,12)
n = 6
wn = 0.2206
[b,a]=butter(n,wn)
얻어진 디지털 필터의 계수입니다.
a는 출력된 값에 곱해지는 계수이며, b는 입력신호에 곱해지는 계수입니다.
b = 0.0019 0.0097 0.0194 0.0194 0.0097 0.0019
a = 1.0000 -2.7685 3.3710 -2.1647 0.7246 -0.1002
<위상 응답> <진폭 특성>
<임펄스 응답> <극점과 영점>
DirectShow Editing Service 에 대해서 :: 2009/06/30 05:47 by 구재현(19기)
동영상 편집을 하기위해서 Microsoft에서 제공하는 최고의 Tool은 바로 DirectShow에서 큰 부분을 차지하고 있는 DirectShow Editing Service(DES)이다.
Microsoft® DirectShow® 편집 서비스 (DES)는, 비디오 편집에 포함되는 태스크를 큰폭으로 간략화하는 애플리케이션 프로그래밍 인터페이스 (API)이다. DES 는, 코어 DirectShow 아키텍처의 최상부에 구축되고 있다. DES 는, DirectShow 의 대부분을 추상화 해, 비디오 편집 프로젝트의 조작 전용에 설계된 일련의 인터페이스를 제공한다. 애플리케이션 개발자는, 비디오 편집 애플리케이션의 생성에 최적인 프레임워크(framework) 중에서 DirectShow 의 이점을 활용할 수 있다.
DirectShow 의 코어가 되는 것은, 스트림 미디어를 처리하기 위한 강력한 아키텍처이다. 개발자가 파일 압축 등의 귀찮은 문제를 고려하지 않아도, 애플리케이션은 DirectShow 를 사용해, 다양한 포맷의 멀티미디어 컨텐츠를 재생할 수 있다. 그러나, DES 가 없으면, DirectShow는 편집에 필요한 유연성을 갖추지 못한다.
예를 들어, 어느 비디오 순서를 생성 하는데, 소스 A 로부터 4 초, 다음에 소스 B 로부터 10 초, 마지막에 소스 C 로부터 5 초를 잇고 싶다고 한다. 이것은, DirectShow API 만을 사용해, 꽤 용이하게 실시할 수가 있다.
그러나, 소스 C 를 소스 B를 가져오기 전에 있고 B를 연결하는 경우나, 소스 A 로부터 4 초는 아니고 8 초 사용하고 싶은 경우, 또 프로덕션 전체로 백그라운드에 다른 오디오 트랙 재생이 필요하게 되었을 경우 등의 작은 변경을 처리 하는 것이 어려운 일이 있다. 그러나, 이러한 작업은 DES 에서는 매우 간단한 편집 프로젝트이며, 메서드 몇 개를 호출하는 것만으로 실시할 수가 있다.
DirectShow 편집 서비스의 아키텍처
다음 그림은 Microsoft® DirectShow® 편집 서비스 (DES)의 아키텍처를 나타내고 있다.
타임 라인 : 비디오 프로덕션을, 소스 클립, 트랜지션, 이펙트의 콜렉션으로서 표현한다. 이러한 콜렉션은, 상자 구조의 일련의 트랙으로서 구성된다.
XML 파서 : 타임 라인을 해석해 출력 파일을 생성한다. 또는, 입력 파일을 읽어들여 타임 라인을 생성한다. DES 는, XML 베이스의 영속성 포맷을 지원 하고 있다.
렌더링 엔진 : 타임 라인을, 스트림 미디어로서 렌더링 할 수 있는 포맷으로 변환한다. 디폴트에서는, 렌더링 엔진은 DirectShow 필터 그래프를 생성한다
미디어 locator : 미디어 요소의 위치의 캐쉬를 보수한다. 미디어 요소를 열려고 실패했을 경우, DES 는 이 캐쉬를 사용해, 성공한 오픈의 History에 근거해 요소를 검색한다.
타임 라인은, 비디오 편집 프로젝트의 추상 표현이다. 이것은, 프로젝트로 사용되는 소스 클립, 그 시작 타임과 종료 타임, 이펙트와 트랜지션등을 지정한다. 그러나, 타임 라인은 비디오 스트림이나 오디오 스트림은 렌더링 하지 않는다. 대신에, 렌더링 엔진은, 프리뷰 또는 파일 출력용으로 타임 라인을 필터 그래프로 변환한다. 애플리케이션에서는, 취급하기 어렵게 에러의 나오기 쉬운 필터 그래프를 직접 조작하는 것이 아니라, 타임 라인을 조작한다.
타임 라인 모델
"타임 라인" 은, Microsof® DirectShow® 편집 서비스 (DES)가 비디오 편집 프로젝트를 표현하기 위해서 사용하는 개체이다. 비디오 프로젝트는, 비디오 파일, 사운드 파일, 정지화면 등의 소스 파일의 콜렉션으로부터 시작된다. 클립의 선형적인 순서가 "트랙" 이 된다. DirectShow 편집 서비스 (DES)에서는, 오디오와 비디오는 다른 트랙에 배치된다.
트랙은, 계층화도 할 수 있다. 복수의 오디오 트랙이 믹싱 되어 페이드나 잔향등의 오디오 이펙트를 포함하는 일도 있다. 복수의 비디오 트랙을 사용해, 트랜지션을 생성 한다. 예를 들어, 어느 클립으로부터 다른 클립에의 와이프를 생성 할 수 있다.
DES 는, 다음과 같이 트리 구조를 사용해 편집을 표현한다.
오디오 클립과 비디오 클립이 리프 노드, 즉 "소스" 개체가 된다. 동일한 미디어 타입 (오디오 또는 비디오)의 소스의 콜렉션이 "트랙" 이다. 트랙의 콜렉션이 "콤포지션" 이다. 콤포지션은, 포함되는 모든 트랙의 콤포지션으로서 렌더링 된다. 콤포지션에는 다른 콤포지션을 넣을 수도 있어 트랙의 복잡한 배치가 가능하다. 콤포지션과 트랙의 최상정도 레벨의 콜렉션이 그룹" 이다. 1 개 또는 복수의 일련의 그룹이 "타임 라인" 이 된다. 타임 라인은, 트리의 루트 노드이다. 타임 라인에는, 적어도 1 개의 그룹이 포함되지 않으면 안 된다. 각 그룹은, 최종 프로덕션에 있어서의 단일의 스트림을 나타낸다. 대표적인 프로젝트에는, 비디오 그룹과 오디오 그룹이 1 개씩 포함된다. 콤포지션은 옵션이며, 필요한 경우에 한층 더 구조를 제공하는 것이다.
다음 그림은 타임 라인을 구성하는 부모와 자식 관계를 나타낸 것이다.
이와 같은 구조를 우리 프로젝트에 투영했을 때의 구조는 다음과 같다.
위의 그림과 같이 각각의 트랙에 해당하는 동영상에서 삽입할 부분을 각각의 소스로 변환 시킨 뒤, 하나의 타임라인을 구성하면 우리 프로젝트에서 하고자 하였던 하나의 완성된 동영상 강의를 만들 수 있게 된다.
[GSS System] SNMP Message Packet Format 분석 :: 2009/06/30 04:30 by 최영특(18기)
지난 블로깅에서는 SNMP의 기본적인 이해에 대해서 알아보았습니다.
이번에는 SNMP를 실제로 이용하기 위해서 SNMP Message Packet Format에 대해서 알아보도록 하겠습니다.
모든 SNMP를 이용하는 장치들은 SNMP Message Format을 이해하고 있어야 합니다. 그 이유 중의 하나가 바로 각기 다른 소프트웨어 개발 Language가 약간씩 다른 data type(Integer, strings, bytes, characters, etc)을 가지고 있기 때문입니다. 예를 들어 SNMP Manager가 Java data type의 message를 보낸다면 C로 작성된 SNMP Agent는 그 message의 내용을 이해하지 못합니다. 이 문제점을 해결하기 위해서 SNMP는 message를 구성하는데 사용하는 data type을 정의한 ASN.1(Abstract Syntax Notation One)을 이용합니다.
ASN.1은 프로그래밍 언어에 독립적이기 때문에, SNMP Agent와 Manager가 어떤 프로그래밍 언어를 이용하더라도 상관이 없습니다. 그러나 이러한 장점에도 불구하고 단점이 한 가지 존재하는데요. 그것은 바로 어떤 특정 data type이 전송될 때 message가 어떻게 encoding되어야 하는가... 하는 것입니다. 예를 들어 Strings type이 C언어로 coding 되어 전송될 경우에는 Null로 끝나고, 다른 언어로 coding되어 전송될 경우에는 다른 형식으로 보내야 할 것입니다. 다른 예로 Boolean value는 C++에서는 8bit, Visual Basic 6에서는 16bit로 구성되는 등 프로그래밍 언어 문법에 따라 달라지는 경우가 있습니다.그래서 ASN.1은 위와 같은 문제점을 해결하기 위해 BER(Basic Encoding Rules)을 포함하고 있습니다. 따라서 모든 data type은 BER에 의해서 선로를 타고 전송되기 전에, 프로그래밍 언어에 상관 없이 동일한 방법으로 encoding 되어집니다.
다시 말해서 SNMP Message의 모든 data field는 ASN.1 data type을 따르고 BER에 의해서 Encoding 됩니다. 그래서 올바른 format의 message를 전송하기 위해서는 ASN.1과 BER(Basic Encoding Rules)을 잘 이해하고 따라야 하는 것입니다.
ASN.1(Abstract Syntax Notation One)
Message를 구성하는데 있어서 ASN.1에 의해 특징지어지는 data type의 몇가지 정보에 대해서 알필요가 있습니다. 그것은 두 가지 category로 나누어지는데, 바로 Primitive 와 Complex 형식 입니다. ASN.1 Primitive data type은 Integer, Octet(byte, characters), String, Null, Boolean, Object Identifier 등을 포함합니다. Object Identifier type의 한 field가 SNMP agent의 parameter를 지시하는데 사용되는 OID를 가지기 때문에 Object Identifier type은 SNMP message의 중요 type이 됩니다. 또한 data를 구성하는 프로그래머의 능력 확장을 위해 여러 primitive data type들을 Groupping 하여 Complex data type을 만들 수 있습니다.
ASN.1은 SNMP Message를 만드는데 필수적인 몇몇 Complex data type을 제공합니다. 첫 번째 complex data type은 Sequence 입니다. Sequence type은 단순히 data field의 list 입니다. Sequence의 field들은 각기 다른 data type을 가질 수도 있습니다. 두 번째 complex data type은 SNMP PDU(Protocol Data Unit) data type 입니다. PDU type은 특히 SNMP에 특화된 complex data type 입니다. 이용가능한 PDU data type은 GetRequest와 SetRequest 인데, 이 놈들은 각각 parameter를 얻어오고, 설정하는데 필수적인 data type이라 할 수 있습니다.
결론적으로 SNMP message는 전체적으로 ASN.1 data type의 field로부터 만들어진 구조입니다. 그러나 정확한 data type의 결정만으로는 부족합니다. 만약 SNMP message가 가변 data type의 Sequence라 한다면, 수신측에서는 어디가 field의 시작이고 어디가 field의 끝인지 어떻게 알 수 있을까요? 또 각 filed의 data type은 무엇인지 어떻게 알 수 있을까요? 이러한 문제점을 회피하기 위해서 BER(Basic Encoding Rules)이 존재하는 것입니다.
BER(Basic Encoding Rules)
SNMP message의 각 field의 byte수를 Layout 할 때에는 Basic Encoding Rules를 따라야 합니다. 가장 기본적인 규칙은 각 field가 세 부분으로 나뉘어서 encoding 된다는 것이다. 세 부분은 바로 Type, Length 그리고 Data 입니다. Type은 한 byte의 식별자를 이용하는 field의 data type을 나타냅니다. Length는 그 뒤에 따라오는 data 부분의 길이를 byte수로 표현한 것입니다. 마지막으로 Data는 실제 Communication하는 값(number, string, OID, etc)이 되겠습니다. Sequences와 PDU 같은 data type들은 몇몇 그보다 작은 field들에 의해서 만들어집니다.
SNMP message를 encoding 하는데는 두 가지 필수적인 Basic Encoding Rules이 있는데, 두 가지 모두 OID encoding에 이용됩니다. 첫 번째 규칙은 OID의 첫 두개 숫자를 encoding 하는데 적용됩니다. BER에 따르면 OID의 첫 두 숫자(16진수 x, y)는 다음과 같은 공식을 따릅니다.
SNMP OID의 첫 두 숫자는 항상 1.3 이므로 SNMP OID의 첫 두 숫자는 항상 43 또는 0x2B로 encoding 됩니다.( because (40 * 1) + y )
첫 두 숫자가 encoding 되고 나서, OID의 연속된 숫자들은 byte 단위로 encoding 됩니다. 여기서 매우 큰 숫자에 대해서 특별한 규칙이 하나 더 있는데요. 1 byte(8 bit)는 0~255까지 밖에 표현 못하기 때문이죠~. 예를 들어서 생각해 볼까요? Rane NM1 microphoneMute OID는 1.3.6.1.4.1.2680.1.2.7.3.2.0 입니다. 여기에서 2680은 1 byte를 이용해서 표현이 불가능 합니다. 이런 경우에는 7 bit 씩 나누어서 표현하는 것이 바로 BER 규칙 중의 하나 입니다. 즉, 1 byte 중 7 bit를 이용해서 값을 표현하고 최상위 bit(MSB)는 flag bit로 이용 합니다. 다음 1 byte를 더 이용하게 되면 flag bit를 1로 둠으로써 다음 byte는 reserved 되었다는 것을 표현하는 것입니다. 위의 경우 2680은 128로 나누면 몫은 20, 나머지는 120이 됩니다. 다시 말해 첫 번째 1 byte는 0x14, 두 번째 1 byte는 0x78가 됩니다. 앞서 말한대로 최상위 bit(flag bit)를 set 시켜줘야하므로 첫 번째 byte는 0x94, 두 번째 byte는 0x78이 되는 것입니다. 검산해보면 (0x14 * 128) + 0x78 = 2680 이 됩니다.
SNMP Message Format
SNMP message format은 message 안에 어떤 field가 포함되어 있는지, 어떤 순서로 배치되어 있는지 나타냅니다. 궁극적으로 message는 이웃한 field의 몇몇 layer들에 의해서 만들어집니다. 가장 바깥쪽 layer에서 SNMP message는 Sequence type의 single field 입니다. 전체 message는 세 개의 작은 field(SNMP Version, SNMP Community String, SNMP PDU) 들로 구성됩니다. 
SNMP PDU로 구성된다.
- SNMP Version : SNMP의 Version을 나타내는 Integer 값. SNMPv1 = 0
- SNMP Community String : SNMP 장치에 보안성을 더해주기 위해 이용되는 문자열을 포함하는
Octet String.
- SNMP PDU : SNMP PDU는 message의 body를 포함한다. PDU는 몇개의 type을 가지는데,
보통 GetRequest, GetResponse, SetRequest로 분류된다.
- Request ID : 특별한 SNMP 요구사항을 식별하는 integer 값.
- Error : 0x00으로 set 된 값이 SNMP manager에 의해서 전송된다. error code는 아래와 같다.
0x00 - 오류 발생 없음.
0x01 - 전송되기에 너무 큰 응답 message.
0x02 - requested object 이름을 찾을 수 없음.
0x03 - 요청된 data type과 SNMP agent의 data type이 다를 때.
0x04 - SNMP manager가 read-only parameter로 설정되었을 때.
0x05 - 일반적인 오류
- Error Index : Error가 발생했을 때, Error Index는 오류를 발생시킨 object를 가리키는 pointer를 가진다.
그렇지 않은 경우에 Error Index는 0x00을 가진다.
- Varbind List : Sequence of Varbinds.
- Varbind : OID & OID's Value.
- Object Identifier : SNMP agent의 특정 parameter를 가리키는 식별자.
- Value : SetRequest PDU - SNMP agent의 특정 OID에 적용된 값.
GetRequest PDU - return data에 대한 유효하지 않은 숫자 Null로서 작용하는 값.
GetResponse PDU - SNMP agent의 특정 OID로부터 return 된 값.
다음 블로깅에서는 실제로 위의 ASN.1 및 BER을 적용하여 팀에서 구현한 Protocol에 대해서
알아보도록 하겠습니다.
감사합니다.
[ 대발이의 그까이꺼~! ] Intelligent Army Robot System 기체 제작 과정 ^^* :: 2009/06/30 00:35 by 조대원(19기)
우리 107팀(25살+26살+28살+28살)의 기체 제작 현황입니다.
이번에 이런저런 이유로 기체제작이 좀 늦어진 감이 있긴 하지만 아주 예쁘게 잘 나왔습니다.^^
기분이 좋군요 ㅋ
일단 시작하기 전에 설계를 맡아주신 민호형님께 감사드립니다 ㅠㅠ
설계하시느라 고생하셨어요~ 형ㅠㅠ
저희 로봇은 말 그대로 지능형 로봇입니다. 스스로 움직이면서 영상인식을 통해 사격을 하는게 궁국적인 목표인 것입니다. 따라서 일단 튼튼하고 정교한, 험한 지형을 주행할 수 있는 기체를 제작해야 했습니다.
일단 제작에 들어가기 전에 설계를 해야겠죠? 당연 설계도 없는 기체란 있을 수 없으니까요.
설계는 Inventor2008을 사용하였습니다. 3차원 설계를 하기위해 사용하는 편리한 Tool이죠^^
본 그림의 경우 원래 부품을 제외한 추가 가공품들 입니다.
[그림 1]
뭔 가공해야 할 부품이 왜 이렇게 많은지.... ㅠ.ㅠ
설계 및 가공시에 가중 중요한 것은 감히 '결합'이라 말할 수 있겠습니다.
물리적인 '힘'을 고려한 설계도 물론 중요하지만 결정적으로 돌아가느냐, 안돌아가느냐는 바로 결합에서 결정나기 때문입니다. 가공 후 조립이 안되면 말짱 꽝이겠죠?
그 외에도 여러가지를 고려해야 했습니다.
4개의 모터를 이용하여 좌측주행, 우측주행, 앞팔, 뒷팔 네군데를 제어하기 위해서 내부 구조가 좀 까다롭게 되어있습니다. 사진으로 찍어놓은게 없어서 아쉽네요 ㅡ; 쩝;;;;
본 사진은 구동부가 모터+벨트+풀리의 결합으로 되어있음을 보입니다.
[사진 2]
위에 '타이밍벨트' 보이시죠? 이 '타이밍벨트'는 제품출하시에 이미 규격이 정해져서 나오므로 규격집에 맞추어 설계를 해주어야 합니다. 물론 '풀리'도 마찬가지 입니다. ('풀리'는 '타이밍벨트'가 끼워지는 바퀴를 의미하죠^^)
아! 그리고 축으로 사용되는 '연마봉'과 앞,뒤팔과의 결합부분 또한 눈여겨 봐야합니다. 연마봉 끝이 그냥 원 모양이면 팔을 들어올릴 수 없겠죠? 측면과 걸리는 부분이 있어야 되잖아요? 그래서 연마봉의 양 끝은 모양이 '반원'입니다. 모든 축과 측면의 결합은 이렇게 구성되어 있습니다. 이것도 사진이 없어서 아쉽네요 ㅡ;;;
이렇게 기본적인 기체의 밑부분에 대한 설명을 마치고 제작과정을 살펴봅시다^^