PDF 파일에 이미 삽입되어 배포된 워터마크를 매우 간단한 방법으로 삭제가 가능하다.
아크로뱃 프로 7을 기준으로 다음과 같은 방법으로 날려보자.
1. 툴바에서 마우스 오른쪽 버튼을 눌러 나타나는 내용 중 [고급 편집] 도구를 활성화 한다.
2. [고급 편집]의 [Touch Up 도구]에서 [Touch Up 개체도구]를 선택한다.
3. 손바닥이 화살표 모양으로 바뀐것을 볼 수 있다.
4. 해당 워터마크를 선택하면 파란 상자로 지울 대상을 지정해 준다.
5. Delete 키를 이용하여 날리면 끝.
2009년 12월 15일 화요일
2009년 12월 1일 화요일
Tinyos-1.x SurgeTelos Bug
tinyos-1.x/apps/SurgeTelos는 tos/lib/MultiHopLQI 라우팅 프로토콜을 사용한다.
tinyos-1.x/tos/lib/MultiHopLQI 에는 치명적인 버그가 하나 존재한다.
tinyos-1.x/tos/lib/MultiHopLQI/MultiHopLQI.nc 파일을 살펴보면 데이터 전송 시 initializeFields에서는 다음과 같이 처리한다.
251 command result_t RouteSelect.initializeFields(TOS_MsgPtr Msg, uint8_t id) {
252 TOS_MHopMsg *pMHMsg = (TOS_MHopMsg *)&Msg->data[0];
253
254 pMHMsg->sourceaddr = pMHMsg->originaddr = TOS_LOCAL_ADDRESS;
255 pMHMsg->originseqno = gCurrentSeqNo;
256 pMHMsg->hopcount = gbCurrentHopCount;
257
258 return SUCCESS;
259 }
여기서 255라인의 gCurrentSeqNo++ 해야 제대로 동작하게 된다.
만약 이 부분의 처리를 해 주지 않고 데이터를 30초당 1개 보다 빠르게 전송하면 데이터 패킷들이 selectRoute안에서 잘못 처리되는(duplicate suppression) 현상이 발생하게 된다.
tinyos-2.x/tos/lib/net/lqi/LqiRoutingEngineP.nc를 보게되면 이곳의 initializeField 함수는 위와 같이 제대로 고쳐져 있음을 확인할 수 있다.
이처럼 tinyos 코드에도 버그가 있음을 유념해야 한다.
tinyos-1.x/tos/lib/MultiHopLQI 에는 치명적인 버그가 하나 존재한다.
tinyos-1.x/tos/lib/MultiHopLQI/MultiHopLQI.nc 파일을 살펴보면 데이터 전송 시 initializeFields에서는 다음과 같이 처리한다.
251 command result_t RouteSelect.initializeFields(TOS_MsgPtr Msg, uint8_t id) {
252 TOS_MHopMsg *pMHMsg = (TOS_MHopMsg *)&Msg->data[0];
253
254 pMHMsg->sourceaddr = pMHMsg->originaddr = TOS_LOCAL_ADDRESS;
255 pMHMsg->originseqno = gCurrentSeqNo;
256 pMHMsg->hopcount = gbCurrentHopCount;
257
258 return SUCCESS;
259 }
여기서 255라인의 gCurrentSeqNo++ 해야 제대로 동작하게 된다.
만약 이 부분의 처리를 해 주지 않고 데이터를 30초당 1개 보다 빠르게 전송하면 데이터 패킷들이 selectRoute안에서 잘못 처리되는(duplicate suppression) 현상이 발생하게 된다.
tinyos-2.x/tos/lib/net/lqi/LqiRoutingEngineP.nc를 보게되면 이곳의 initializeField 함수는 위와 같이 제대로 고쳐져 있음을 확인할 수 있다.
이처럼 tinyos 코드에도 버그가 있음을 유념해야 한다.
2009년 11월 11일 수요일
TOSBase & Network Communication Lib
TOSBase 와 Network Communication Lib. 에 대해 알아보자.
TOSBase 어플리케이션은 Bridge 역할을 한다.
즉, 송신 노드로부터 RF를 통해 전달되는 패킷을 수신하게 되면 TOSBase는 Group ID를 확인하고 자신의 Group ID 와 같으면 패킷을 받아서 시리얼(PC)로 전송하는 기능을 하며, 반대로 시리얼(PC)로부터 데이터를 전달 받으면 RF를 통해 네트워크로 전송하는 기능을 한다.
TOSBase 어플리케이션은 네트워크를 사용하는 다른 어플리케이션들과는 약간 다른 네트워크 라이브러리를 사용한다.
TOSBase 어플리케이션의 경우 RadioCRCPacket 라이브러리를 사용하는데 다음과 같다.
components Main, TOSBaseM, RadioCRCPacket as Comm, FramerM, UART, LedsC, CC2420ControlM;
RadioCRCPacket 라이브러리는 패킷을 받으면 CRC 체크후 에러가 없으면 상위 컴퍼넌트로 전달한다. RadioCRCPacket을 통해 올라온 패킷은 에러체크만 하고, 그룹 ID나 노드 ID는 필터링 되지 않는다.
TOSBase 어플리케이션이 RadioCRCPacket 라이브러리를 쓰는 이유는 네트워크로 수신되는 모든 패킷을 받기 위함이다.
그에 반해 OscilloscopeRF와 같은 일반적인 어플리케이션은 GenericComm 라이브러리를 사용한다.
GenericComm 라이브러리는 RadioCRCPacket을 통해 올라온 패킷들 중에서 그룹 ID와 노드 ID가 자신의 ID와 일치하는 브로드캐스팅된 패킷만 필터링 해서 상위 컴퍼넌트로 올려주는 역할을 한다.
즉, GenericComm 네트워크 스택을 사용하면 자신의 ID 또는 브로드캐스팅 주소로 전송되는 패킷만 수신하게 되는 것이다.
GenericComm과 RadioCRCPacket이 각각의 동작방식은 다르지만 제공하는 command와 event는 같으며, 일반적으로 컴포넌트명도 비슷하게 사용한다.
TOSBase 어플리케이션의 TOSBaseM.nc 파일과 OscilloscopeRF 어플리케이션의 oscilloscopeM.nc파일만 비교해보면 네트워크와 관련해서 같은 라이브러리를 사용하는 것처럼 보일 수가 있다.
그렇기 때문에 TOSBase.nc파일과 Oscilloscope.nc파일을 비교해 보면서 두 어플리케이션에서 각각 어떤 네트워크라이브러리를 사용하는지 알수가 있고 차이점을 파악할 수 있다.
그리고 RF를 통해 네트워크로 전송되는 패킷마다 패킷 ID를 가지며, 이 ID를 가지고 적절한 핸들러를 찾아 이벤트를 발생시켜주는데, 이 이벤트 핸들러는 상위 컴포넌트에서 구현해야 한다.
참고로 OscopeMsg.h 파일을 보면 다음과 같이 선언되어 있는 것을 볼 수 있다.
enum {
AM_OSCOPEMSG = 10,
AM_OSCOPERESETMSG = 32,
};
이처럼 네트워크를 이용하는 다른 어플리케이션들은 이와 비슷한 형태로 패킷별로 고유의 ID를 정해서 사용한다.
네트워크로 패킷이 수신되었을 때 그룹 ID와 노드 ID가 자신의 ID와 동일하더라도 패킷 ID에 대한 핸들러를 구현해놓지 않았으면 해당 패킷은 무시된다.
configuration 부분을 보시면 하위 컴포넌트들과 연결할 때 이 ID를 다음과 같이 지정해서 사용하는 것을 볼 수 있다.
OscilloscopeM.ResetCounterMsg -> Comm.ReceiveMsg[AM_OSCOPERESETMSG];
OscilloscopeM.DataMsg -> Comm.SendMsg[AM_OSCOPEMSG];
위의 경우 패킷을 전송할 때는 AM_OSCOPEMSG 를 패킷에 삽입하여 전송하고, 수신되는 패킷은 AM_OSCOPERESETMSG 를 ID로 가지는 패킷만 처리하겠다는 것을 의미한다.
단순히 Oscilloscope를 수정하여 send와 receive를 하게 되면 보내는 쪽에서는 AM_OSCOPEMSG를 패킷 ID로해서 보내지만, 수신측에서는 AM_OSCOPERESETMSG를 패킷 ID로 가지는 것만 필터링 해서 받기 때문에 전송측에서 보내는 패킷을 받을 수가 없게 된다.
그러므로 네트워크와 관련된 내용을 구현할 때는 configuration 파일을 잘 살펴보고 사용하는 라이브러리와 패킷 ID를 주의하여 사용해야 한다.
TOSBase 어플리케이션은 Bridge 역할을 한다.
즉, 송신 노드로부터 RF를 통해 전달되는 패킷을 수신하게 되면 TOSBase는 Group ID를 확인하고 자신의 Group ID 와 같으면 패킷을 받아서 시리얼(PC)로 전송하는 기능을 하며, 반대로 시리얼(PC)로부터 데이터를 전달 받으면 RF를 통해 네트워크로 전송하는 기능을 한다.
TOSBase 어플리케이션은 네트워크를 사용하는 다른 어플리케이션들과는 약간 다른 네트워크 라이브러리를 사용한다.
TOSBase 어플리케이션의 경우 RadioCRCPacket 라이브러리를 사용하는데 다음과 같다.
components Main, TOSBaseM, RadioCRCPacket as Comm, FramerM, UART, LedsC, CC2420ControlM;
RadioCRCPacket 라이브러리는 패킷을 받으면 CRC 체크후 에러가 없으면 상위 컴퍼넌트로 전달한다. RadioCRCPacket을 통해 올라온 패킷은 에러체크만 하고, 그룹 ID나 노드 ID는 필터링 되지 않는다.
TOSBase 어플리케이션이 RadioCRCPacket 라이브러리를 쓰는 이유는 네트워크로 수신되는 모든 패킷을 받기 위함이다.
그에 반해 OscilloscopeRF와 같은 일반적인 어플리케이션은 GenericComm 라이브러리를 사용한다.
GenericComm 라이브러리는 RadioCRCPacket을 통해 올라온 패킷들 중에서 그룹 ID와 노드 ID가 자신의 ID와 일치하는 브로드캐스팅된 패킷만 필터링 해서 상위 컴퍼넌트로 올려주는 역할을 한다.
즉, GenericComm 네트워크 스택을 사용하면 자신의 ID 또는 브로드캐스팅 주소로 전송되는 패킷만 수신하게 되는 것이다.
GenericComm과 RadioCRCPacket이 각각의 동작방식은 다르지만 제공하는 command와 event는 같으며, 일반적으로 컴포넌트명도 비슷하게 사용한다.
TOSBase 어플리케이션의 TOSBaseM.nc 파일과 OscilloscopeRF 어플리케이션의 oscilloscopeM.nc파일만 비교해보면 네트워크와 관련해서 같은 라이브러리를 사용하는 것처럼 보일 수가 있다.
그렇기 때문에 TOSBase.nc파일과 Oscilloscope.nc파일을 비교해 보면서 두 어플리케이션에서 각각 어떤 네트워크라이브러리를 사용하는지 알수가 있고 차이점을 파악할 수 있다.
그리고 RF를 통해 네트워크로 전송되는 패킷마다 패킷 ID를 가지며, 이 ID를 가지고 적절한 핸들러를 찾아 이벤트를 발생시켜주는데, 이 이벤트 핸들러는 상위 컴포넌트에서 구현해야 한다.
참고로 OscopeMsg.h 파일을 보면 다음과 같이 선언되어 있는 것을 볼 수 있다.
enum {
AM_OSCOPEMSG = 10,
AM_OSCOPERESETMSG = 32,
};
이처럼 네트워크를 이용하는 다른 어플리케이션들은 이와 비슷한 형태로 패킷별로 고유의 ID를 정해서 사용한다.
네트워크로 패킷이 수신되었을 때 그룹 ID와 노드 ID가 자신의 ID와 동일하더라도 패킷 ID에 대한 핸들러를 구현해놓지 않았으면 해당 패킷은 무시된다.
configuration 부분을 보시면 하위 컴포넌트들과 연결할 때 이 ID를 다음과 같이 지정해서 사용하는 것을 볼 수 있다.
OscilloscopeM.ResetCounterMsg -> Comm.ReceiveMsg[AM_OSCOPERESETMSG];
OscilloscopeM.DataMsg -> Comm.SendMsg[AM_OSCOPEMSG];
위의 경우 패킷을 전송할 때는 AM_OSCOPEMSG 를 패킷에 삽입하여 전송하고, 수신되는 패킷은 AM_OSCOPERESETMSG 를 ID로 가지는 패킷만 처리하겠다는 것을 의미한다.
단순히 Oscilloscope를 수정하여 send와 receive를 하게 되면 보내는 쪽에서는 AM_OSCOPEMSG를 패킷 ID로해서 보내지만, 수신측에서는 AM_OSCOPERESETMSG를 패킷 ID로 가지는 것만 필터링 해서 받기 때문에 전송측에서 보내는 패킷을 받을 수가 없게 된다.
그러므로 네트워크와 관련된 내용을 구현할 때는 configuration 파일을 잘 살펴보고 사용하는 라이브러리와 패킷 ID를 주의하여 사용해야 한다.
2009년 11월 8일 일요일
CC2420의 전원 제어
tinyos 에서 cc2420의 제어와 관련된 컴포넌트는 CC2420RadioC 에서 담당한다. 여기서 cc2420 칩 자체의 전원을 컨트롤 할 수 있다.
CC2420Control.VREFOn() 과 CC2420Control.VREFOff() 를 사용하면 된다.
하지만 이를 사용하게 되면 전원이 On/Off 되는 과정에서 칩 자체의 초기화를 다시 해야 하는 불편함이 따른다.
그래서...
CC2420 칩 자체의 전원을 차단하지 않는 방법이 있다. 오실레이터라는 것을 이용하는 것이다.
CC2420Control.OscillatorOn()과 CC2420Control.OscillatorOff()를 사용하게 되면 칩 전원을 제어하는데 필요한 초기화등이 불필요 하므로 좀 더 효과적으로 사용할 수 있다.
CC2420Control.VREFOn() 과 CC2420Control.VREFOff() 를 사용하면 된다.
하지만 이를 사용하게 되면 전원이 On/Off 되는 과정에서 칩 자체의 초기화를 다시 해야 하는 불편함이 따른다.
그래서...
CC2420 칩 자체의 전원을 차단하지 않는 방법이 있다. 오실레이터라는 것을 이용하는 것이다.
CC2420Control.OscillatorOn()과 CC2420Control.OscillatorOff()를 사용하게 되면 칩 전원을 제어하는데 필요한 초기화등이 불필요 하므로 좀 더 효과적으로 사용할 수 있다.
CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance)
센서 네트워크 기반에서 주로 사용되는 MAC 프로토콜 방식으로 물리계층과 네트워크 계층 사이에서 센서 노드 간 원활한 데이터 전송을 위해 직접 관여한다.
이는 데이터를 보내기 전에 보내고자 하는 채널 또는 링크에 다른 데이터가 전송되고 있는지 미리 확인하는 과정을 통해 해당 채널 또는 링크에 사용자가 없으면 이 때 자신의 데이터를 실어 보내는 방식을 취한다.
이는 데이터를 보내기 전에 보내고자 하는 채널 또는 링크에 다른 데이터가 전송되고 있는지 미리 확인하는 과정을 통해 해당 채널 또는 링크에 사용자가 없으면 이 때 자신의 데이터를 실어 보내는 방식을 취한다.
2009년 11월 5일 목요일
non-overlapping channel
Bluetooth나 Ieee 802.11b/g등 수 많은 무선 기기들이 노출되어 있는 환경에서 노이즈 또는 충돌없이 신뢰성 있는 통신을 위해서는 동 주파수 대역내에서 중첩되는 채널의 회피 방안은 필수이다.
CC2420 RF Chip이 사용하는 2.4Ghz 대역은 ISM 영역으로 많은 통신 표준들이 이 주파수 대역을 사용하고 있다.
이 대역을 사용하는 무선 통신들은 노이즈나 충돌이 발생하게 된다.
(IEEE 국제 표준은 비영리 목적으로 사용되기 때문에...)
특히 이 주파수 영역에 영향을 미치는 것은 역시 802.11 AP들이다.
만약 해당 사용자 중 하나가 스트리밍 서비스를 무선 인터넷을 통해 받고 있으면 그 영역은 엄청난 손실이 발생하게 된다.
하지만 802.11 역시 해당 대역을 나누어 채널별로 사용하고 있다.
802.11은 미국기준으로 2.4Ghz에서 11개의 채널을 사용하게되는데, 이 채널은 서로간의 대역을 조금씩 침범하고 있으므로, 동시에 한 공간에서 11개의 채널을 충돌없이 사용할 수는 없다. 동시에 서로의 영향없이 사용할 수 있는 채널을 non-overlap 채널이라고 하는데, 이것은 11개의 채널들 중 1번, 6번, 11번 채널이다.
이 3가지 채널은 한 공간에서 동시에 사용해도 이론상으로 서로의 대역을 침범하지 않는다.
이 3가지 802.11의 non-overlap 채널들과 802.15.4(cc2420)의 채널들을 비교하면, cc2420이 제공하는 11번부터 26번 채널 중, 15번, 20번, 25번, 26번 채널은 802.11과 겹치지 않아 노이즈가 적으므로, 비교적 좋은 통신 성능을 보이게 된다.
만약 주변에 AP가 있을 경우, 15, 20, 25, 26번 채널을 선택하는 것이 좋고, AP가 없다면 802.15.4의 채널은 모두 서로 간에 non-overlap이기 때문에 어떠한 채널을 선택해도 큰 상관은 없다.
CC2420 RF Chip이 사용하는 2.4Ghz 대역은 ISM 영역으로 많은 통신 표준들이 이 주파수 대역을 사용하고 있다.
이 대역을 사용하는 무선 통신들은 노이즈나 충돌이 발생하게 된다.
(IEEE 국제 표준은 비영리 목적으로 사용되기 때문에...)
특히 이 주파수 영역에 영향을 미치는 것은 역시 802.11 AP들이다.
만약 해당 사용자 중 하나가 스트리밍 서비스를 무선 인터넷을 통해 받고 있으면 그 영역은 엄청난 손실이 발생하게 된다.
하지만 802.11 역시 해당 대역을 나누어 채널별로 사용하고 있다.
802.11은 미국기준으로 2.4Ghz에서 11개의 채널을 사용하게되는데, 이 채널은 서로간의 대역을 조금씩 침범하고 있으므로, 동시에 한 공간에서 11개의 채널을 충돌없이 사용할 수는 없다. 동시에 서로의 영향없이 사용할 수 있는 채널을 non-overlap 채널이라고 하는데, 이것은 11개의 채널들 중 1번, 6번, 11번 채널이다.
이 3가지 채널은 한 공간에서 동시에 사용해도 이론상으로 서로의 대역을 침범하지 않는다.
이 3가지 802.11의 non-overlap 채널들과 802.15.4(cc2420)의 채널들을 비교하면, cc2420이 제공하는 11번부터 26번 채널 중, 15번, 20번, 25번, 26번 채널은 802.11과 겹치지 않아 노이즈가 적으므로, 비교적 좋은 통신 성능을 보이게 된다.
만약 주변에 AP가 있을 경우, 15, 20, 25, 26번 채널을 선택하는 것이 좋고, AP가 없다면 802.15.4의 채널은 모두 서로 간에 non-overlap이기 때문에 어떠한 채널을 선택해도 큰 상관은 없다.
2009년 11월 2일 월요일
LDT(Location Determination Technology)
GPS 또는 이에 준하는 무선 네트워크의 기지국 위치를 활용하여 서비스 요청 단말기의 정확한 위치를 파악하는 기술.
[ 거리정보 기반 위치측정 ]
1. ToA (Time of Arrival)
전송노드가 신호를 발생시켜 신호가 목적노드에 도달한 시간을 거리로 변환시키는 기술.
ToF(Time of Fight)라고 불리기도 함.
소리 or 초음파와 같은 신호를 전송하여 목적지에 도달하기까지의 시간에 신호의 속도를 곱한 값이 거리가 됨.
두 노드간 신호의 전송시간을 정확하게 하기 위해 양 단말간 클럭의 동기화가 정확히 이뤄져야함.
대표적인 예로 GPS가 있음
2. TDoA(Time Difference of Arrival)
속도가 다른 두 신호를 동시에 전송하여 목적지에 도착하는 시간의 차이를 거리로 환산하는 기술.
일반적으로 초음파 신호와 라디오 신호를 동시에 전송하며, 라디오 신호는 빛의 속도로 진행되고 초음파 신호는 음속으로 진행되는 속도의 차이를 이용함.
절대적인 시간 정보 없이 시간차를 이용하므로 동기화가 필요하진 않지만 실제로 동시에 두 신호를 보내기 어려우므로 오차 보정 방식을 취함.
3. AoA(Angle of Arrival)
센서에서 타깃이 보내는 신호의 방향각을 이용하여 각을 측정하고 각 센서와 타깃 사이의 방향각 교차점을 계산하여 타깃의 위치를 측정하는 기술.
최소 2개 이상의 방향각들이 필요하며 이들을 교차시킴으로써 위치 파악이 가능함.
타깃이 센서와 멀리 있다는 가정에 근거를 두어, 가까울 경우 주변환경에 의해 산란이 되어 부적절.
* 위 기술 모두 LOS에 의존하여야 하지만 Non-LOS지역의 반사와 굴절로 인해 측정에 오류가 발생함. 이를 해결하기 위해 많은 논문들이 해결책을 제시하고 있음
4. RSSI : 수신신호의 세기에 기반을 둔 위치측정
RSSI(Received Signal Strength Indication)는 신호를 수신한 노드가 신호의 강도를 이용하여 신호가 감쇄된 정도를 거리로 환산하는 방법.
미리 정의된 다양한 지점에서 신호 세기들을 RSSI 표본 수집을 통해 측정 후 타깃의 송신 신호를 각 센서들이 수신할 때 발생하는 신호의 감쇠정도를 측정한 뒤 이를 확률적 방법을 통해 미리 수집되었던 RSSI 표본과 매칭하여 위치 측정.
장애물이 존재하거나 복잡한 실내 환경일 경우 거리 측정 오차가 매우 큼.
[거리정보에 기반을 두지 않은 위치인식 기술]
1. 중점기법
앵커의 비컨 신호를 사용하며 타겟의 위치는 다수의 앵커로부터 한 홉으로 인식이 가능한 공통된 지역의 중심으로 나타냄.
2. APIT(Approximate Point In Triangle)
한 홉으로 연결이 가능한 앵커들로 삼각형을 형성하고, 타겟 노드가 그 삼각형 내부에 있는지의 여부를 인식한 후, 타겟노드를 포함하는 삼각형 영역의 중첩된 영역의 중심점을 타겟의 위치로 결정하는 알고리즘.
앵커는 수많은 삼각형을 형성하기 위해 전송범위가 긴 방향성 안테나를 장착해야 함.
타겟노드를 포함한 일반 미지노드들은 앵커로부터 수신된 신호의 세기를 측정할 수 있어야 함.
[ 거리정보 기반 위치측정 ]
1. ToA (Time of Arrival)
전송노드가 신호를 발생시켜 신호가 목적노드에 도달한 시간을 거리로 변환시키는 기술.
ToF(Time of Fight)라고 불리기도 함.
소리 or 초음파와 같은 신호를 전송하여 목적지에 도달하기까지의 시간에 신호의 속도를 곱한 값이 거리가 됨.
두 노드간 신호의 전송시간을 정확하게 하기 위해 양 단말간 클럭의 동기화가 정확히 이뤄져야함.
대표적인 예로 GPS가 있음
2. TDoA(Time Difference of Arrival)
속도가 다른 두 신호를 동시에 전송하여 목적지에 도착하는 시간의 차이를 거리로 환산하는 기술.
일반적으로 초음파 신호와 라디오 신호를 동시에 전송하며, 라디오 신호는 빛의 속도로 진행되고 초음파 신호는 음속으로 진행되는 속도의 차이를 이용함.
절대적인 시간 정보 없이 시간차를 이용하므로 동기화가 필요하진 않지만 실제로 동시에 두 신호를 보내기 어려우므로 오차 보정 방식을 취함.
3. AoA(Angle of Arrival)
센서에서 타깃이 보내는 신호의 방향각을 이용하여 각을 측정하고 각 센서와 타깃 사이의 방향각 교차점을 계산하여 타깃의 위치를 측정하는 기술.
최소 2개 이상의 방향각들이 필요하며 이들을 교차시킴으로써 위치 파악이 가능함.
타깃이 센서와 멀리 있다는 가정에 근거를 두어, 가까울 경우 주변환경에 의해 산란이 되어 부적절.
* 위 기술 모두 LOS에 의존하여야 하지만 Non-LOS지역의 반사와 굴절로 인해 측정에 오류가 발생함. 이를 해결하기 위해 많은 논문들이 해결책을 제시하고 있음
4. RSSI : 수신신호의 세기에 기반을 둔 위치측정
RSSI(Received Signal Strength Indication)는 신호를 수신한 노드가 신호의 강도를 이용하여 신호가 감쇄된 정도를 거리로 환산하는 방법.
미리 정의된 다양한 지점에서 신호 세기들을 RSSI 표본 수집을 통해 측정 후 타깃의 송신 신호를 각 센서들이 수신할 때 발생하는 신호의 감쇠정도를 측정한 뒤 이를 확률적 방법을 통해 미리 수집되었던 RSSI 표본과 매칭하여 위치 측정.
장애물이 존재하거나 복잡한 실내 환경일 경우 거리 측정 오차가 매우 큼.
[거리정보에 기반을 두지 않은 위치인식 기술]
1. 중점기법
앵커의 비컨 신호를 사용하며 타겟의 위치는 다수의 앵커로부터 한 홉으로 인식이 가능한 공통된 지역의 중심으로 나타냄.
2. APIT(Approximate Point In Triangle)
한 홉으로 연결이 가능한 앵커들로 삼각형을 형성하고, 타겟 노드가 그 삼각형 내부에 있는지의 여부를 인식한 후, 타겟노드를 포함하는 삼각형 영역의 중첩된 영역의 중심점을 타겟의 위치로 결정하는 알고리즘.
앵커는 수많은 삼각형을 형성하기 위해 전송범위가 긴 방향성 안테나를 장착해야 함.
타겟노드를 포함한 일반 미지노드들은 앵커로부터 수신된 신호의 세기를 측정할 수 있어야 함.
2009년 10월 4일 일요일
zigbee RF 주파수 특성
zigbee RF 특성
zigbee에서 대표적으로 사용하는 주파수인 2.4GHz 영역 주파수의 일반적인 전달특성은 직접파와 반사파에 의존하며 회절에 의한 전파 전송이 잘 안 되는 특성이 있다.
다음은 2.4GHz 대역 zigbee 모듈의 RF 규격이다.
자유대역에서 전파
자유공간에서의 zigbee의 무선 파의 전파(propagation)특성을 확인하기 위하여 거리 별 수신레벨과 PER(Packet Error Rate)을 측정해 보면 송신 지점에서 200m 떨어진 지점까지는 PER 0%이며, 이 때의 평균 수신레벨은 -92dBm이며 200m 이후 지점부터의 수신레벨의 감소폭은 작아지나 패킷 에러율이 급상승한다.
가정 내의 전파환경
가정 내의 무선 전송 환경은 자유공간과 달리 무선 전송을 방해하는 여러 가지 장애물들로 가득하다. 고정된 장애물도 있고 이동하는 장애물들도 있는데, 고정된 장애물인 내부 벽의 투과 손실은 10~30dB이며 벽의 종류, 두께, 콘크리트 내부 철재의 구조, 전파의 입사각 등에 의해 투과 손실은 각각 다르게 나타난다. 같은 구조의 집에서도 무선 전송 환경은 각각 다르므로 예측에 의한 무선망 설계는 실수로 이어질 수 있으며, 이를 방지하기 위해서는 zigbee 전용 패킷 툴과 같은 전파 환경 측정 장치를 사용하는 것이 바람직하다.
유동적인 장애물의 경우 사람의 이동, 문의 개폐, 가구 또는 가전제품의 재배치등이 있다. 문의 개폐 상황에 따른 전파환경 변화에 대한 대책으로는 망 설계 시 모든 문을 닫고 설계하여 통신 안정성을 확보하는 방법이 있으나, 사람의 이동이나 가구 등의 재배치에 따른 환경변화에는 별 다른 대책이 없으므로 변화에 대응이 가능한 정도의 여분을 주어 네트워크의 안정성을 확보해야 한다.
가정 내에서의 전파환경은 다른 무엇보다도 내부 구조에 가장 큰 영향을 받는 것으로 확인되며, 집의 크기에 의한 영향은 비교적 적다. 이러한 원인으로는 같은 구조의 50평형대와 30평형대의 아파트의 중심에서 가장자리까지의 거리차이는 2~3m 차이 밖에 나지 않기 때문이다. 벽을 몇 개를 통과하는지, 벽의 두께 및 재질이 무엇인지, 반사파가 어떤 경로로 도달하는지 등이 가정 내 무선전송의 거리를 형성하는 주요 변수이다. 신축현장에서는 이러한 벽의 두께 및 벽 내부의 철근 구조 등을 비교적 알기 쉽고, 아파트의 경우 동일 크기에 같은 구조이므로 비교적 전송거리의 결정이 쉬우나, 단독주택과 같은 경우에는 설치자가 직접 측정에 의해 전송거리를 결정해야만 안정적인 통신을 보장 받을 수 있다.
주파수 간섭
zigbee 기기들은 가정 내에서는 WLAN, Bluetooth와 같은 동일한 주파수 대역을 사용하는 기기들과 공존하면서 동작이 되어야 한다. 그러므로 이들 간의 간격 또한 zigbee 기술을 이용한 홈네트워크 방법에서는 중요한 요소로 작용한다. zigbee가 채택한 PHY/MAC 규격인 IEEE 802.15.4는 주파수 대역으로 2.4GHz를 권고하고 있으며, 현재 대부분의 zigbee 기기들은 Bluetooth, WLAN등이 사용하는 주파수 대역인 2.4GHz 대역의 칩을 사용하므로 이들 무선기술간의 간섭이 문제로 부각되고 있다. 이 간섭 문제를 적극적으로 해결하기 위해서 근본적으로 간섭을 피하려는 노력을 하고 있다.
zigbee에서 대표적으로 사용하는 주파수인 2.4GHz 영역 주파수의 일반적인 전달특성은 직접파와 반사파에 의존하며 회절에 의한 전파 전송이 잘 안 되는 특성이 있다.
다음은 2.4GHz 대역 zigbee 모듈의 RF 규격이다.
- 변조방식 : DSSS/O-QPSK
- 사용주파수 : 2400 ~ 2483.5MHz
- 최대송신속도 : 250Kbps
- 최대출력파워 : 10dBm
- 최저수신감도 : -94dBm
- 채널 수 : 16
- 채널간격 : 5MHz
자유대역에서 전파
자유공간에서의 zigbee의 무선 파의 전파(propagation)특성을 확인하기 위하여 거리 별 수신레벨과 PER(Packet Error Rate)을 측정해 보면 송신 지점에서 200m 떨어진 지점까지는 PER 0%이며, 이 때의 평균 수신레벨은 -92dBm이며 200m 이후 지점부터의 수신레벨의 감소폭은 작아지나 패킷 에러율이 급상승한다.
가정 내의 전파환경
가정 내의 무선 전송 환경은 자유공간과 달리 무선 전송을 방해하는 여러 가지 장애물들로 가득하다. 고정된 장애물도 있고 이동하는 장애물들도 있는데, 고정된 장애물인 내부 벽의 투과 손실은 10~30dB이며 벽의 종류, 두께, 콘크리트 내부 철재의 구조, 전파의 입사각 등에 의해 투과 손실은 각각 다르게 나타난다. 같은 구조의 집에서도 무선 전송 환경은 각각 다르므로 예측에 의한 무선망 설계는 실수로 이어질 수 있으며, 이를 방지하기 위해서는 zigbee 전용 패킷 툴과 같은 전파 환경 측정 장치를 사용하는 것이 바람직하다.
유동적인 장애물의 경우 사람의 이동, 문의 개폐, 가구 또는 가전제품의 재배치등이 있다. 문의 개폐 상황에 따른 전파환경 변화에 대한 대책으로는 망 설계 시 모든 문을 닫고 설계하여 통신 안정성을 확보하는 방법이 있으나, 사람의 이동이나 가구 등의 재배치에 따른 환경변화에는 별 다른 대책이 없으므로 변화에 대응이 가능한 정도의 여분을 주어 네트워크의 안정성을 확보해야 한다.
가정 내에서의 전파환경은 다른 무엇보다도 내부 구조에 가장 큰 영향을 받는 것으로 확인되며, 집의 크기에 의한 영향은 비교적 적다. 이러한 원인으로는 같은 구조의 50평형대와 30평형대의 아파트의 중심에서 가장자리까지의 거리차이는 2~3m 차이 밖에 나지 않기 때문이다. 벽을 몇 개를 통과하는지, 벽의 두께 및 재질이 무엇인지, 반사파가 어떤 경로로 도달하는지 등이 가정 내 무선전송의 거리를 형성하는 주요 변수이다. 신축현장에서는 이러한 벽의 두께 및 벽 내부의 철근 구조 등을 비교적 알기 쉽고, 아파트의 경우 동일 크기에 같은 구조이므로 비교적 전송거리의 결정이 쉬우나, 단독주택과 같은 경우에는 설치자가 직접 측정에 의해 전송거리를 결정해야만 안정적인 통신을 보장 받을 수 있다.
주파수 간섭
zigbee 기기들은 가정 내에서는 WLAN, Bluetooth와 같은 동일한 주파수 대역을 사용하는 기기들과 공존하면서 동작이 되어야 한다. 그러므로 이들 간의 간격 또한 zigbee 기술을 이용한 홈네트워크 방법에서는 중요한 요소로 작용한다. zigbee가 채택한 PHY/MAC 규격인 IEEE 802.15.4는 주파수 대역으로 2.4GHz를 권고하고 있으며, 현재 대부분의 zigbee 기기들은 Bluetooth, WLAN등이 사용하는 주파수 대역인 2.4GHz 대역의 칩을 사용하므로 이들 무선기술간의 간섭이 문제로 부각되고 있다. 이 간섭 문제를 적극적으로 해결하기 위해서 근본적으로 간섭을 피하려는 노력을 하고 있다.
- zigbee803 -
2009년 9월 29일 화요일
Kaist의 김진수 교수님께서 작성하신 공감 100배
Kaist의 김진수 교수님께서 제자들에게 전하고자 하는 내용이라고 한다.
정말 가슴 깊이 생각하고 공감하게 만드는 글의 내용이다.
다음은 그 내용의 전문이다.
--------------------------------------------------------------------
Weekly reports만 올라오니 너무 썰렁해지는 것 같아서..
대학원 생활을 하는 여러분에게 평소에 하고 싶었던 말 몇 가지를 적어봅니다.
Computer Science/Engineering 연구
물리학, 화학, 수학과 같은 자연과학은 신이 만들어 놓은 자연의 이치를 깨닫고자 하는 학문입니다. 진짜 신이 수소, 산소, 질소 등등의 각종 원소를 이용해서 물질을 만들게 하셨는지는 아무도 모릅니다. 단지 과학자들이 하는 일은 현상을 잘 설명할 수 있는 그럴듯한 가설을 만들고 그것이 현상을 제대로 설명하는지를 확인하는 일을 반복할 뿐입니다. 따라서 자연과학에는 "왜?" 그렇게 되었는지에 대해서 물을 필요도 없고, 단지 발견과 경탄만이 존재할 뿐입니다.
그러나 우리가 업으로 삼고 있는 computer science 혹은 computer engineering 분야는 신이 만든 것이 아니라 사람이 만들어 놓은 computer system을 학문의 대상으로 합니다. 따라서, 자연과학과는 본질적으로 학문의 성격이 틀릴 수 밖에 없습니다. Computer science에서의 연구는 어떻게 돌아가는지 "발견"을 하는 연구가 아니라, "왜" 그렇게 만들었는지를 알아내고, "어떻게 하면" 더 잘 만들 수 있을까 위주로 연구가 이루어지게 됩니다. 몇몇 사람들에게 이미 우스개소리로 말한 바 있지만, 결국 연구의 시작은 남이 한 일에 대해서 트집을 잡는 것부터 시작되는 것입니다. 논문을 하나 읽으면, 그 논문의 아이디어는 무엇인지, 어떻게 자신의 아이디어가 좋다고 설득을 했는지, 그리고 문제점이나 제한점은 무엇인지 분석하는 습관을 항상 들이기 바랍니다. 이러한 것을 생각해 보지 않는다면, 아무리 많은 논문을 읽어도 연구에 별 도움이 되지 않습니다. (영어에는 도움이 됨)
결국은 창의력 싸움
웅진 씽크빅 CF에서 "이젠 창의력이 경쟁력"이라는 말이 나오는데 예전에는 저도 창의력이 그렇게 중요한지 아무 생각이 없었습니다만, 요즘 들어서는 결국은 창의력이 문제라는 생각을 하게 됩니다. 일단 다른 사람이 한 일에 대해서 트집을 잡았다면, 자신이 했다면 어찌 했을지를 생각해 보아야 하는데 이 부분에서 창의력 있는 사람과 창의력 없는 사람이 드러납니다. 만일 몇몇 논문을 읽고, 중요한 것은 다른 사람들이 이미 모두 파먹어서 나는 별로 할게 없다는 생각이 드는 사람은 일단 자신의 창의력을 의심해 보기 바랍니다. 당신이 그렇게 생각하고 시간을 보내는 사이에도, 꾸준하게 새로운 논문들이 쓰여지고 있습니다.
처음부터 창의력이 있고, 창의력이 없는 사람이 있는 것은 아니라고 봅니다. 창의력은 계속 이것저것을 생각해 보는 훈련에 의해 충분히 그 역량이 늘어날 수 있습니다. 한가지 권장하고 싶은 방법은, 어떤 논문의 introduction만을 읽고, 혼자 생각해 보는 방법입니다. 논문의 introduction을 읽으면, 그 논문이 대상으로 하고 있는 background와 문제점, motivation 등이 나옵니다. 그럼, 그 부분에서 논문 읽는 것을 중지하고, 해당 문제점을 해결하기 위해 자신이라면 어떤 식으로 approach 하겠는지를 생각해 봅니다. 또한, 그것을 어떤 방법으로 실험하고 다른 사람에게 설득했겠는지를 생각해 봅니다. 마치, 연구 topic이 주어졌을 때 본인이 그것에 대한 논문을 쓴다고 생각하고 자유롭게 풀어나가라는 뜻입니다. 그런 다음, 논문의 나머지 부분을 읽어보고 자신의 생각과 비교해 봅니다. 비교를 하면 보통 세가지 경우 중의 하나입니다. 첫째, 자신의 생각이 너무 단순해서 논문의 related work에 나와있는 경우 - 그 정도로는 안된다는 뜻이죠. 둘째, 자신의 생각과 논문의 아이디어가 거의 비슷할 때 - 아쉽지만 나도 할 수 있다는 자신감을 갖게 됩니다. 셋째, 논문의 아이디어나 related work에 나와 있는 내용과 다를 때 - 새로운 논문이 될지도 모릅니다. 그러나 다른 사람이 이미 했을지도 모르니 관련 연구를 다시 자세히 조사해 보는 것이 필요합니다.
대개의 경우 관련 연구를 조사해 보면, 누군가 이미 한 경우가 대부분이지만, 혹시 아무도 자기가 생각한 것을 시도해 보지 않았다면... 결과가 좋게만 나온다면 새로운 논문이 될 가능성이 많습니다. 그러나 십중팔구, 아이디어는 좋은 것 같아서 시도해 보았는데 결과는 생각보다 좋지 않은 경우가 또 대부분입니다. ㅠ.ㅠ 이 경우, 어떤 사람들은 결과가 좋지 않으니 더 해 볼 생각도 안하고 거기서 그냥 하던 일을 접곤 합니다. 그러나 그렇게 되면 투자한 시간과 노력이 전부 날라가게 됩니다. 그 보다는, 무엇때문에 자신이 생각하던 결과와 차이가 나는지를 분석하고, 원래의 아이디어를 수정하고 optimize 해 나가는 것이 바람직합니다.
가끔 제가 여러분에게 이러저러한 일을 해 보면 어떻겠냐고 할 때에는, 저도 그 결과가 좋을지 나쁠지 정확히 알 수 없는 경우가 대부분입니다. 어렵게 일을 해서 결과를 뽑으면 결과가 안 좋게 나올 때도 있을 것입니다. 그렇다고 해서 거기서 주저앉지 말고, 그 결과를 어떻게 하면 활용하고, 향상시킬 수 있는지 고민하는 사람이 되었으면 좋겠습니다. 한 두 번 생각해서 좋은 생각이 떠오르지 않는다고 포기하면 안 됩니다. 그 정도로 해결이 될 것이라면 이미 누군가는 시도해 보았을 가능성이 많기 때문입니다. 자나 깨나 밥먹을 때나 샤워할 때나 문제를 생각하다 보면 좋은 생각이 떠오르는 때가 틀림없이 있을 것입니다. 정 안되어서 문제를 해결할 수가 없더라도, 자신이 시간과 노력을 들인 일에 대해서는 어떻게 하던지 논문으로 정리를 하기 바랍니다. 논문 내용이 아무리 해도 더 이상 안되더라..가 되더라도 말입니다.
Discussion의 중요성
창의적인 아이디어는 항상 처음에는 허황되게 보이기 마련입니다. 허황되어 보이는 아이디어를 다른 사람들이 그럴듯하다고 생각되게 만드는 과정이 연구입니다. 자신의 아이디어를 발전시키는 중요한 방법 중의 하나는 다른 사람과 discussion을 하는 것입니다. Discussion을 하는 것은 여러가지 면에서 연구에 중요한 도구입니다. 다른 사람에게 자신의 생각을 논리적으로 설명하려다 보면, 자신의 아이디어도 정리되고, 자신이 빼먹고 있었던 사실도 알게 됩니다. 그리고, 일반적인 경우 다른 사람의 아이디어를 들으면 대부분의 사람들은 부정적인 입장에서 공격을 하게 됩니다. 그러면 그러한 사람들을 설득시키는 과정에서 자신의 아이디어의 장단점이 무엇인지 파악되고, 새로운 아이디어가 나오게 됩니다.
물론 제가 여러분의 discussion 상대가 되겠지만, 여러분끼리의 discussion도 많으면 많을수록 좋겠습니다. 간혹 보면, 이것은 나의 일이고, 저것은 쟤가 맡은 일이라서 서로 간섭하지 않으려고 하는 경향이 있으나 그것은 결코(!) 바람직하지 않습니다. 남이 무슨 일을 하고 있는지 알아서 서로서로 도움을 주고 받을 수 있는 문화가 되었으면 좋겠습니다. 제가 weekly reports를 공개적으로 이 곳 게시판에 올리게 하는 이유도 자신이 하는 일 뿐만이 아니라 다른 사람이 무엇을 하고 있는지에 대해서도 관심을 가지게 하기 위함입니다.
실험에 대한 사전 고려
어떤 아이디어가 좋다는 것을 다른 사람에게 설득하기 위해서는 무엇이 좋아지는지 구체적인 증거를 들이밀어야 합니다. 구체적인 실험 결과가 없이 단지 말로만 이것이 저렇게 좋아진다고 하는 것은 software engineering 같은 데서는 통할지 몰라도, 우리 분야에는 통하지 않습니다. 따라서, 아이디어가 좋다고 해도, 그것을 증명할 방법을 찾지 못하면 그것은 무용지물입니다. (진짜 아이디어가 좋다면 특허는 낼 수 있습니다. 특허에는 아이디어가 좋다고 증명할 필요가 없으므로...)
결국, 적당한 실험이 뒷받침되지 않은 아이디어는 허공에 대고 메아리치는 격입니다. 이것은 바꿔 말하면, 아이디어를 발전시켜 나가는 초기부터 어떻게 실험을 해야 할지 미리미리 고려를 해야 한다는 뜻입니다. 만일, 어떤 주제에 대해서 연구를 시작할 때, 우리가 가지고 있는 infrastructure를 가지고 실험을 해 볼 수 있는 것인지를 함께 생각해 보기 바랍니다. 실제 implementation을 할 수 있겠는지, 아니면 필요한 simulator를 얻을 수 있는지, benchmark로는 무엇을 사용하면 되는지 등등에 대해서 사전 검토가 필요합니다.
이러한 점에서 저는 예전에 비해 연구 환경이 매우 나아졌다고 생각합니다. 예를 들어, 제가 학교 다닐 때에는 우리나라에서 OS나 architecture에 대해서 연구하기가 매우 힘들었습니다. OS에 관한 아이디어가 있어도 OS source code가 없으니 implement 해 볼 방법이 없었고, architecture에 관한 연구도 이와 사정이 비슷하였습니다. 그러나 이제는 Linux와 같이 source code가 가용한 OS를 이용할 수 있으니, 무언가를 해 볼 수 있는 여지가 많이 생겼습니다. 저는 Linux를 좋아하고 즐겨 사용하지만, open source니 뭐니 그런 것 보다도, 일단 연구의 중요한 도구라는 점에 의의를 두고 있습니다. 이제는 Linux 상에서 무언가를 했다고 해도 그 사실만으로는 태클을 받지 않는 정도의 수준까지 올라왔으니, 학교의 입장에서는 연구를 하는데에 굉장히 큰 도움이 되는 것은 사실입니다. Architecture에서도 요즘에는 SimpleScalar와 같은 좋은 시뮬레이터들이 많이 있어서 연구에 활용되고 있으니, 이제 실험을 못해서 논문을 쓰기 어렵다는 핑계를 대기도 힘들어 졌습니다.
어쨌거나 요약하면, 적절한 실험을 통하여 검증해 볼 수 있는 아이디어만을 일단 연구의 대상으로 하는 것이 좋겠다는 것입니다. 이렇게 하면 단지 장비나 실험 환경이 없어서 여러분의 좋은 아이디어가 사장될 지는 모릅니다. 그러나 검증할 수 없는 아이디어에 대해서 시간을 보내고 있기에는 여러분의 시간이 너무나 한정되어 있습니다. 졸업들 빨리 해야죠...
많은 사람의 관심이 되는 topic vs. 일부의 사람들만 관심있는 topic
연구 topic, 특히 박사학위 논문 topic에는 두가지가 있습니다. 하나는 아주 일부의 사람들만 관심이 있는 topic입니다. 이것은 community도 작고, 관련된 컨퍼런스나 워크샵도 수가 작습니다. 일부의 사람들만 관심이 있는 이유는 다른 사람들이 별로 중요하지 않다고 생각하거나, 현실성이 없거나, 너무 미래지향적이거나 하기 때문입니다. 다른 하나는 많은 사람들이 현재 active하게 연구하고 있는 topic입니다. 이런 분야는 많은 사람들이 달라 붙어있기 때문에 논문도 많이 발표되고 굉장히 속도가 빠르게 진행됩니다.
전자의 경우에는 사람들이 적기 때문에, 경쟁도 그리 심하지 않고, 시간적인 여유도 있고, 잘(!)만하면 비교적 쉽게 논문을 쓸 수 있을 가능성이 있습니다. 그러나 그렇게 논문을 쓴다고 해도 일부의 사람들만 인정을 할 뿐입니다. 반면, 후자의 분야는 내가 하고 있는 것을 남이 한 발 앞서 할 수도 있고, 경쟁도 매우 심하지만, 일단 그런 경쟁을 뚫고 논문을 발표하게 되면, 많은 사람들이 자신이 한 일에 대해서 관심도 갖고 국제적인 지명도도 얻게 됩니다.
두 가지 종류의 topic 중 어떤 것을 선택할 지는, 개개인의 성향입니다. 저보고 추천하라고 하면, 저는 힘들지만 후자를 선택하라고 하겠습니다. 많은 사람들이 연구하는 topic에서 일을 하는 것은 많은 시간과 노력과 때로는 좌절을 수반하지만, 그만큼 보람도 큰 법입니다. 제가 앞서 중요한 conference 들을 언급하였는데, 그러한 conference에 논문을 발표한다는 것은 여러분이 후자의 일을 하고 있다는 뜻입니다.
능동적/공격적인 연구
능동적 연구라고 함은 누가 시키지 않아도 스스로 연구를 해 나아갔으면 좋겠다는 뜻이고, 공격적인 연구라 함은 논문쓰는 것을 두려워 하지 말라는 뜻입니다.
능동적인 연구를 강조하는 이유가 교수가 논문지도 안하고 놀기 위함은 절대(!) 아닙니다. 석사건, 박사건, 졸업을 하는 것은 지도교수보다는 본인의 역량이라는 점을 명심하시기 바랍니다. 지도교수가 밥상을 차려줄 수는 있어도, 밥을 먹는 것은 본인입니다. 제가 석사 신입생들 면접할 때도 얘기를 했는데, 대학원은 제가 여러분을 귀찮게 하는 곳이 아니라, 여러분이 저를 귀찮게 하는 곳입니다. 언제라도 어떤 문제에 대해 저와 얘기하고 싶다면 제게 찾아오시기 바랍니다. 대부분 제가 잘 알지 못하는 내용이 될 가능성이 높지만서두...^^. 가끔 보면 지도교수가 옆에서 이거해 봐라, 저거해 봐라 하는 경우에는 왜 하는지도 모르고 별로 신도 나지 않은 채로 일을 하지만, 지도교수가 아무 신경도 쓰지 않으면 오히려 불안해서 스스로 연구를 하게 되는 경우가 많은 것 같습니다. 저도 여러분의 졸업과 관련하여서는 귀찮게 하지 않을 작정이니 졸업하고 싶으면 스스로 알아서 하세요.
공격적으로 연구를 하라는 것은 좋은 논문 하나에 집착하지 말라는 뜻입니다. 간혹 보면 대학원, 특히 박사과정에 들어오면 박사 논문 topic을 찾아 헤매서 돌아다니고, 그 외의 일은 신경도 쓰지 않는 것을 봅니다. 큰 거 한 방을 찾는 거죠. 하지만, 논문도 써 본 사람이 잘 쓰는 법입니다. 실제 박사논문 topic을 잡아서 집중적으로 일을 하기 전에, 작은 아이디어라도 논문으로 만들어 내어 보고, 영어 엉터리라고 reject도 당해 보고, accept 되어 다른 사람들 앞에서 영어로 발표도 해 보고 할 기회를 갖기를 바랍니다. 몇 번 해 보면, 대충 어떻게 돌아가는 건지 감도 잡히고, 실제 본 무대에서 뛸 때 도움이 됩니다. 야구 선수들도 처음에는 minor league에서 연습하다가 major league에서 뛰는 것과 마찬가지로, 작은 아이디어라도 실험 결과를 뽑고, 논문으로 만들어서 좀 떨어지는 컨퍼런스나 워크샵에라도 발표하려는 노력을 하기 바랍니다. 제가 생각하기에는 박사 1-2년차때 석사논문 내용이나, 수행한 project, course term project에서 한 일들을 가지고 major/minor conference에 한 두 개의 논문을 발표해 보고, 박사 3년차 이후에 본격적으로 자신의 topic에 대해서 연구하여 major conferences에 논문 2개 이상, 그리고 journal 논문 하나 이상 정도를 쓰고 졸업을 하면 좋겠습니다. 석사과정의 경우에도, 웬만한 conference에 실을 수 있을 정도가 되어야 석사 논문으로 적당합니다. 석사 논문을 쓰면 그것을 정리해서 conference나 정보과학회 논문지에 내어 보는 것을 권장합니다.
또 하나, 능동적/공격적인 연구와 관련하여 제가 강조하고 싶은 것은, 앞에서도 얘기했지만 절대 혼자서 모든 것을 다하려고 하지 말라는 것입니다. 좋은 아이디어가 있으면 혼자 끙끙거리지 말고, 다른 사람과 상의하고 일을 나누어서 하세요. 혼자서 논문 2개 쓰는 것보다, 둘이서 논문 4개 쓰는 것이 훨씬 쉽습니다. 그리고, 같이 일하는 사람이 후배일 경우에는 후배에게 일을 가르쳐주는 효과도 있게 되겠죠.
마지막으로, 대학원에 들어올 때는 순서대로 들어오지만, 졸업은 반드시 들어온 순서대로가 아니라는 점입니다. 때로는 선배를, 혹은 교수를 뛰어 넘어 자신의 능력을 발휘하는 여러분이 되기 바랍니다. 그리고, 석사과정에 있다 하더라도 반드시 4학기를 채워야 할 필요는 없습니다. 3학기만에 조기졸업을 할 수도 있고, 이제 석박사 통합과정이라는 것도 생겼으니 필요하면 이용하시기 바랍니다.
논문의 first author
논문을 쓸 때 주의할 점은 아이디어를 낸 사람이 반드시 first author가 되는 것은 아니라는 점입니다. First author는 기본적으로 해당 논문을 작성할 때 주도적으로 writing을 한 사람입니다. 즉, 아이디어를 A가 냈다고 하더라도, 논문을 B가 썼다면 B가 first author가 된다는 것입니다. 이것은 아이디어를 내는 것에 못지 않게 그 아이디어를 구체적으로 논문화하는 데에도 많은 시간과 노력이 들어가기 때문입니다. 그러니 아이디어내고, 실험 결과만 뽑았다고 해서 자동적으로 first author가 되는 것은 아니라는 점을 명심하시기 바랍니다. 논문의 first author가 되기 위해서는 그 논문을 실제로 본인이 작성해야 합니다.
연구는 타/이/밍
항상 computer systems에서도 resource management가 문제가 되는데, 여러분의 대학원 생활에도 자원 관리, 특히 여러분의 시간 관리가 중요합니다. 대학원, 특히 박사과정에서는 어리버리 하다 보면 시간이 금새 지나가는 수가 많습니다. 박사 1-2년차에는 랩일 하고, 코스웍 듣고 하다 보면 가고, 3년차는 뭔가 해 봐야지 하면서 보내고, 4년차가 되면 슬슬 초조해지기 시작하는데 박사논문 topic은 잘 안 잡히고, 5년차에 다행이 topic하나 잡아서 한 6개월 죽어라 일을 하고 간신히 졸업하면 다행... 인 것이 잘못하면 걷게 되는 여러분의 운명입니다.
일단 가장 문제가 되는 것은 빨리 졸업해야 되겠다는 motivation의 부재입니다. 그냥 사람들 좋고, 시간 여유 많고, 사회에 나가는 것도 두렵고, 그러다가 보면 대학원 생활에 익숙해 지고, 왜 대학원에 있는지도 모르고, 빨리 나가고 싶은 생각도 없고 그렇게 됩니다. 국내 대학원에 있는 사람과 유학간 사람들을 비교해 볼 때, 대부분 국내에서 박사학위를 하는 사람들이 상대적으로 performance가 떨어진다고들 합니다. 이것이 원래 부지런하고 자기 앞가림하는 사람들이 유학을 갔기 때문이라고 보는 사람도 있으나, 저는 기본적으로 국내에서 박사학위를 하는 대학원생들이 유학간 사람들에 비해 motivation과 긴장도가 떨어지고 열심히 하지도 않기 때문이라고 생각합니다. 제가 그래봤기 때문에 잘 압니다.
여러분이 할 일이 많다는 것은 저도 잘 아나, 대학원에 있는 동안 만이라도 일단은 연구에 우선 순위를 두었으면 하는 것이 제 바램입니다. 졸업하고도 할 수 있는 일은 대학원에 있는 동안은 잠시 미뤄두세요. 그게 싫다고요? 그러면 열심히 연구해서 빨리 졸업하고 그 다음에 하고 싶은 것 실컷 하면 되지 않습니까? 이렇게 얘기한다고 해서 매일 모니터 앞에만 앉아있으라는 말은 아닙니다. 사람이 연구만 하면서 살 수는 없으니까 가끔 기분전환도 하고 술도 마시고, 게임도 하고 그래야 되겠죠. 따라서 결국은 시간 관리를 잘 해야 하는 문제가 되는데, 제가 볼때는 생산성과 집중력이 중요합니다.
연구는 타이밍입니다. 특히 많은 사람들이 관심을 가지고 있는 topic에 대해서 일을 할 경우에는 더욱 그러합니다. 나에게 참신한 아이디어가 있더라도, 내가 어리버리하면서 시간을 보내고 있는 사이 다른 사람이 비슷한 아이디어를 발표해 버리면 내가 들인 시간은 물거품이 됩니다. 가끔 어떤 참신한 아이디어가 있으면, 저는 빨리 결과 뽑아서 논문으로 만들고 싶은데, 정작 그 일을 하는 학생은 여유를 가지고 일을 하는 바람에 제 속만 타는 경우가 있습니다. 저는 누가 먼저 발표할까봐 불안해 죽겠는데 말이죠. 따라서, 같은 일을 하더라도 1년 내내 일을 꾸준히 성실하게 하는 사람보다는, 6개월에 집중해서 끝내고 나머지 6개월을 탱자탱자 보내는 사람이 훨씬 더 낫습니다.
학자적 양심
나중에 졸업 등에 스트레스를 받게 되면 한순간 실험 결과를 조작하고 싶은 충동이나 다른 사람의 아이디어를 내 것인냥 슬쩍 빌려오는 등의 유혹을 받게 될 경우가 있는데, 이것은 무!조!건! 절!대! 안 됩니다. 왜냐고요? 바로 학자적 양심 때문입니다. 도덕적인 양심이 있듯이, 배운 사람에게는 학자적 양심이라는게 있습니다. 누가 강요하지 않아도 스스로 지켜야 할 선이 있는 거죠.
일전에 우연히 정보과학회 춘계 학술대회 논문집을 넘겨보다가, 우리 랩 학생이 말도 안 되는 논문을 낸 것을 보고 혼낸 적이 있습니다. 이미 웬만한 사람은 다 알만한 내용을, 심지어 예제 코드로도 많이 나오는 내용을 논문이랍시고 버젓이 쓴 것이 실렸기 때문입니다. 물론 정보과학회 학술대회 논문집을 살펴보면 말도 안되는 논문들이 많은 것은 사실이고, 그런 논문들이 심사 과정에서 걸러지지 않는 것도 문제이긴 합니다. 또한, 정보과학회 학술대회 논문의 경우에는 교수님들께서 일일이 신경을 쓰시지도 않고요. 그러나 그렇다고 해서 그런 논문을 실을 수는 없는 일입니다. 왜냐하면, 많은 사람들이 KAIST에서는 도대체 무슨 일을 하고 있는지 주의 깊게 살펴보고 있기 때문이죠. 여러분이 허접한 논문을 발표하면 여러분 논문 발표 실적에 한 줄 더 쓸 수는 있겠지만, KAIST나 여러분의 지도교수, 혹은 여러분 자신의 얼굴에 먹칠을 하게 되는 것입니다. 많이 배울수록, 스스로 지켜야 할 선의 수준도 높아지기 마련입니다.
KAIST의 특수성
마지막으로 여러분에게 부탁하고 싶은 점은, 특히 KAIST 학생으로서의 책임감을 가져달라는 점입니다. KAIST는 다른 학교와는 달리 많은 부분을 정부의 지원, 그러니까 국민의 세금에 의존하고 있는 학교입니다. 여러분 한명을 교육시키기 위하여 여러분의 부모님들을 포함한 얼마나 많은 사람들이 일하고 세금을 내는지 생각해 보기 바랍니다. 그렇게 여러분을 믿고 지원해 준 국민들에게 보답하기 위해서라도, 좋은 연구하고 빨리 졸업해서 사회에 보탬이 되는 일을 하는 것이 바람직합니다. 만일 여러분이 하라는 공부는 안 하고 게임하면서 하루하루를 지세운다면, 제가 보기에는 공적자금 빼돌리는 악덕 기업주와 다를 바가 없습니다.
많은 KAIST 학생들이 자신은 머리가 좋기 때문에, 아니면 여기까지 온 것도 경쟁을 뚫고 들어온 것이기 때문에 이만한 혜택을 받을 자격이 있다고 생각하는 경향이 있습니다. 그러나 사장이 되기까지 힘들었으니 이제 돈을 빼돌려도 된다는 것이 합리화되지 않는 것처럼, 여러분이 KAIST 학생이 되었다는 것이 여러분이 받고 있는 혜택을 당연하게 만드는 것은 아닙니다. 때로 여러분이 지치거나 힘들 때, 얼마나 많은 학생들이 여러분과 함께 KAIST에 들어오고 싶어 했고, 지금도 KAIST에서 공부하기를 꿈꾸면서 얼마나 많은 후배들이 공부하고 있는지 생각해 보기 바랍니다.
이것이 석사논문 주제가 되나요? (version 0.2 추가)
많은 학생들이 찾아와서는 묻습니다. "제게 이러저러한 아이디어가 있는데 이것이 석사논문 주제로 적당할까요?" 라고요. 태어날 때 천한 사람, 귀한 사람이 따로 있는 것이 아니듯이, 저는 처음부터 석사논문으로 적당한 topic이 따로 있는 것은 아니라고 생각합니다. 어떤 topic이 석사논문으로 적당한 지의 여부는 전적으로 그것을 주장하는 여러분에게 달려 있습니다. 즉, 여러분이 그것이 왜 중요하고, 어떤 점이 나아지며, 다른 사람이 한 일과는 어떻게 다른지를 논문 committee에 있는 교수님들이나 다른 사람들에게 효과적으로 설득할 수 있는지의 여부가 더욱 중요하다는 점입니다. 학위논문 심사를 보통 디펜스(defense) 한다고 하는데, 이것은 많은 사람들의 공격으로부터 자신이 한 일이 중요하다는 것을 설득시키고 지켜낼 수 있어야 하기 때문입니다.
자기의 논문을 디펜스하기 위하여 무엇보다도 중요한 것은 앞에서도 언급했듯이 다양하고 많은 사람들과의 discussion 입니다. 혼자서 생각하다보면 한쪽으로만 생각이 흐르는 경향이 있어서 중요한 것을 못보고 지나칠 가능성이 많습니다. 그러나 백그라운드가 다른 여러 사람에게 자기가 한 일을 설명하고 이해시키려고 하다 보면, 그 사람들이 이해하지 못하는 점을 설명해 주는 과정에서 놓치고 있던 것을 발견하게 되고 더 좋은 아이디어가 떠오르게 되기도 합니다. 또, 얘기를 하다 보면, 사람들이 여러가지를 물고 늘어지면서 시비를 걸게 되는데, 이런 점에 대해서 미리 대답을 생각해 보고 하면 실제 논문심사시에도 훨씬 여유가 있게 됩니다. 결국 논문심사를 위해 여러분이 준비해야 할 것은 이런 질문에는 이렇게 대답하고, 저런 질문에는 저렇게 대답하고.. 등을 미리 생각해 놓아야 하는 것인데, 당연히 예상문제를 많이 풀어보고 들어가는 것이 유리합니다. 그러니 다른 사람과의 discussion은 많으면 많을수록 좋습니다.
보통 어떤 논문에 대해서 눈여겨 보는 것은,
1. 어떤 환경 혹은 시나리오를 가정하고 있는가?
2. 가정하고 있는 환경에서 어떤 문제가 있는가?
3. 그 문제가 왜 중요한 문제인가?
4. 문제 해결을 위한 본인의 아이디어는 무엇인가?
5. 같은 문제 해결을 위해 다른 사람들이 기존에 한 일은 무엇인가?
6. 다른 사람들이 한 일과 본인이 한 일이 *객관적*이고 *정량적*으로 잘 비교, 분석되었는가?
7. 혹시 나빠지는 점은 없는가?
등등입니다. 위의 물음에 대해 자신을 가지고 다른 사람을 설득할 수 있으면 됩니다.
제 개인적으로, 석사논문의 수준은 웬만한 conference에 accept될 수 있는 정도면 적당하다고 생각합니다. 이 말은 바꿔말하면, 여러분이 작성하는 석사논문이 웬만한 conference의 심사위원들을 설득할 수 있는 정도의 수준이 되어야 한다는 뜻입니다.
세미나 참석 (version 0.2 추가)
아이디어를 얻기 위해서 또 하나 강조하고 싶은 것은 세미나 참석입니다. 보통 대학원 연구실 배정을 받고 나면 언제부터 본인에게 연구분야가 있었다고 자기 연구분야가 아니면 세미나에 흥미조차 없는 사람들이 많습니다. 그러나, 앞으로 여러분이 어떤 일을 하게 될지 모르고, 그런 기회가 아니라면 다른 분야에서 어떤 일을 하는지 조차 모르게 되니 가급적 학과/학교에서 열리는 세미나에는 시간을 내어 참석하기 바랍니다. 그 시간에 여러분이 논문을 하나 읽는 것보다, 해당 분야에 대해서 잘 정리해서 발표해 주는 세미나를 듣는 것이 훨씬 도움이 됩니다.
그리고 결국 전산학에서 어떤 문제를 풀기 위한 approach는 거의 비슷하기 때문에, 다른 사람들이 어떤 문제를 어떤 식으로 풀어나갔는지를 보는 것이 많은 도움이 됩니다. 그리고 어떤 경우에는 전혀 다른 분야에서 쓰는 방법을 내 분야에 적용시켰을 때 매우 효과적인 경우도 많습니다. 따라서, 아무리 다른 분야의 세미나라 하더라도 세미나를 들으면서 자유롭게 내가 알고 있는 분야에 비슷한 문제는 없는지 등을 생각해 보는 것이 좋습니다. 내용을 모르더라도 최소한 발표는 어떻게 하는 것이 좋겠는지, 혹은 질문에 대해 어떻게 대처해야 하는지 등에 관해서라도 배울 수 있는 이점이 있으니 세미나 참석은 중요합니다. 같은 이유로 대학원 때 수업도 본인의 연구 분야에 관련된 부분만 집중해서 듣지 말고, 다른 분야의 과목들을 듣는 것을 권장합니다.
흔히, 박사학위의 기본 요건 중의 하나가 T자형 인간이라고 합니다. 그러니까 전산학 전 분야에 대해서 breadth와 자기 분야에서의 depth를 가져야 한다는 것이죠. 보통 자격고사(qualifying exam)를 통해 breadth를 테스트 하고, depth는 박사학위논문심사에서 따지게 됩니다. 우리 학교의 경우 자격고사가 제 역할을 하고 있지 못해서 좀 문제이기는 하지만.. 아뭏든 둘 다 중요하니 자기 분야의 depth만 고집할 게 아니라, 다른 분야에서 어떤 일들이 일어나고 있는지도 관심을 가지고 살펴보기 바랍니다. 그게 다 피가 되고, 살이 됩니다.
----
쓰다 보니 조금 훈계조로 흐른 부분도 없지 않고, 일부는 몇몇 사람에게 얘기한 적도 있는데.... 정리하는 차원에서 쓴 것이니 참고하기 바랍니다. 또 다른 생각이 나면 지속적으로 업데이트 하도록 하겠습니다.
아래는 참고할 만한 링크입니다.
Useful Links on Graduate Studies, Research, and Technical Communication
Graduate School Survival Guide (by Wanda Pratt)
Guides to Surviving Computer Science Graduate School (by Ronald Azuma)
Advice on Research and Writing
Graduate Studies, Research and Careers in Computer Science
An Evaluation of the Ninth SOSP Submissions or How (and How Not) to Write a Good Systems Paper
How to Have a Bad Career in Research/Academia (Also at David Patterson's homepage)
Resources for Writers and Writing Instructors (by Jack Lynch)
임재춘의 과학기술자 글쓰기
정말 가슴 깊이 생각하고 공감하게 만드는 글의 내용이다.
다음은 그 내용의 전문이다.
--------------------------------------------------------------------
Weekly reports만 올라오니 너무 썰렁해지는 것 같아서..
대학원 생활을 하는 여러분에게 평소에 하고 싶었던 말 몇 가지를 적어봅니다.
Computer Science/Engineering 연구
물리학, 화학, 수학과 같은 자연과학은 신이 만들어 놓은 자연의 이치를 깨닫고자 하는 학문입니다. 진짜 신이 수소, 산소, 질소 등등의 각종 원소를 이용해서 물질을 만들게 하셨는지는 아무도 모릅니다. 단지 과학자들이 하는 일은 현상을 잘 설명할 수 있는 그럴듯한 가설을 만들고 그것이 현상을 제대로 설명하는지를 확인하는 일을 반복할 뿐입니다. 따라서 자연과학에는 "왜?" 그렇게 되었는지에 대해서 물을 필요도 없고, 단지 발견과 경탄만이 존재할 뿐입니다.
그러나 우리가 업으로 삼고 있는 computer science 혹은 computer engineering 분야는 신이 만든 것이 아니라 사람이 만들어 놓은 computer system을 학문의 대상으로 합니다. 따라서, 자연과학과는 본질적으로 학문의 성격이 틀릴 수 밖에 없습니다. Computer science에서의 연구는 어떻게 돌아가는지 "발견"을 하는 연구가 아니라, "왜" 그렇게 만들었는지를 알아내고, "어떻게 하면" 더 잘 만들 수 있을까 위주로 연구가 이루어지게 됩니다. 몇몇 사람들에게 이미 우스개소리로 말한 바 있지만, 결국 연구의 시작은 남이 한 일에 대해서 트집을 잡는 것부터 시작되는 것입니다. 논문을 하나 읽으면, 그 논문의 아이디어는 무엇인지, 어떻게 자신의 아이디어가 좋다고 설득을 했는지, 그리고 문제점이나 제한점은 무엇인지 분석하는 습관을 항상 들이기 바랍니다. 이러한 것을 생각해 보지 않는다면, 아무리 많은 논문을 읽어도 연구에 별 도움이 되지 않습니다. (영어에는 도움이 됨)
결국은 창의력 싸움
웅진 씽크빅 CF에서 "이젠 창의력이 경쟁력"이라는 말이 나오는데 예전에는 저도 창의력이 그렇게 중요한지 아무 생각이 없었습니다만, 요즘 들어서는 결국은 창의력이 문제라는 생각을 하게 됩니다. 일단 다른 사람이 한 일에 대해서 트집을 잡았다면, 자신이 했다면 어찌 했을지를 생각해 보아야 하는데 이 부분에서 창의력 있는 사람과 창의력 없는 사람이 드러납니다. 만일 몇몇 논문을 읽고, 중요한 것은 다른 사람들이 이미 모두 파먹어서 나는 별로 할게 없다는 생각이 드는 사람은 일단 자신의 창의력을 의심해 보기 바랍니다. 당신이 그렇게 생각하고 시간을 보내는 사이에도, 꾸준하게 새로운 논문들이 쓰여지고 있습니다.
처음부터 창의력이 있고, 창의력이 없는 사람이 있는 것은 아니라고 봅니다. 창의력은 계속 이것저것을 생각해 보는 훈련에 의해 충분히 그 역량이 늘어날 수 있습니다. 한가지 권장하고 싶은 방법은, 어떤 논문의 introduction만을 읽고, 혼자 생각해 보는 방법입니다. 논문의 introduction을 읽으면, 그 논문이 대상으로 하고 있는 background와 문제점, motivation 등이 나옵니다. 그럼, 그 부분에서 논문 읽는 것을 중지하고, 해당 문제점을 해결하기 위해 자신이라면 어떤 식으로 approach 하겠는지를 생각해 봅니다. 또한, 그것을 어떤 방법으로 실험하고 다른 사람에게 설득했겠는지를 생각해 봅니다. 마치, 연구 topic이 주어졌을 때 본인이 그것에 대한 논문을 쓴다고 생각하고 자유롭게 풀어나가라는 뜻입니다. 그런 다음, 논문의 나머지 부분을 읽어보고 자신의 생각과 비교해 봅니다. 비교를 하면 보통 세가지 경우 중의 하나입니다. 첫째, 자신의 생각이 너무 단순해서 논문의 related work에 나와있는 경우 - 그 정도로는 안된다는 뜻이죠. 둘째, 자신의 생각과 논문의 아이디어가 거의 비슷할 때 - 아쉽지만 나도 할 수 있다는 자신감을 갖게 됩니다. 셋째, 논문의 아이디어나 related work에 나와 있는 내용과 다를 때 - 새로운 논문이 될지도 모릅니다. 그러나 다른 사람이 이미 했을지도 모르니 관련 연구를 다시 자세히 조사해 보는 것이 필요합니다.
대개의 경우 관련 연구를 조사해 보면, 누군가 이미 한 경우가 대부분이지만, 혹시 아무도 자기가 생각한 것을 시도해 보지 않았다면... 결과가 좋게만 나온다면 새로운 논문이 될 가능성이 많습니다. 그러나 십중팔구, 아이디어는 좋은 것 같아서 시도해 보았는데 결과는 생각보다 좋지 않은 경우가 또 대부분입니다. ㅠ.ㅠ 이 경우, 어떤 사람들은 결과가 좋지 않으니 더 해 볼 생각도 안하고 거기서 그냥 하던 일을 접곤 합니다. 그러나 그렇게 되면 투자한 시간과 노력이 전부 날라가게 됩니다. 그 보다는, 무엇때문에 자신이 생각하던 결과와 차이가 나는지를 분석하고, 원래의 아이디어를 수정하고 optimize 해 나가는 것이 바람직합니다.
가끔 제가 여러분에게 이러저러한 일을 해 보면 어떻겠냐고 할 때에는, 저도 그 결과가 좋을지 나쁠지 정확히 알 수 없는 경우가 대부분입니다. 어렵게 일을 해서 결과를 뽑으면 결과가 안 좋게 나올 때도 있을 것입니다. 그렇다고 해서 거기서 주저앉지 말고, 그 결과를 어떻게 하면 활용하고, 향상시킬 수 있는지 고민하는 사람이 되었으면 좋겠습니다. 한 두 번 생각해서 좋은 생각이 떠오르지 않는다고 포기하면 안 됩니다. 그 정도로 해결이 될 것이라면 이미 누군가는 시도해 보았을 가능성이 많기 때문입니다. 자나 깨나 밥먹을 때나 샤워할 때나 문제를 생각하다 보면 좋은 생각이 떠오르는 때가 틀림없이 있을 것입니다. 정 안되어서 문제를 해결할 수가 없더라도, 자신이 시간과 노력을 들인 일에 대해서는 어떻게 하던지 논문으로 정리를 하기 바랍니다. 논문 내용이 아무리 해도 더 이상 안되더라..가 되더라도 말입니다.
Discussion의 중요성
창의적인 아이디어는 항상 처음에는 허황되게 보이기 마련입니다. 허황되어 보이는 아이디어를 다른 사람들이 그럴듯하다고 생각되게 만드는 과정이 연구입니다. 자신의 아이디어를 발전시키는 중요한 방법 중의 하나는 다른 사람과 discussion을 하는 것입니다. Discussion을 하는 것은 여러가지 면에서 연구에 중요한 도구입니다. 다른 사람에게 자신의 생각을 논리적으로 설명하려다 보면, 자신의 아이디어도 정리되고, 자신이 빼먹고 있었던 사실도 알게 됩니다. 그리고, 일반적인 경우 다른 사람의 아이디어를 들으면 대부분의 사람들은 부정적인 입장에서 공격을 하게 됩니다. 그러면 그러한 사람들을 설득시키는 과정에서 자신의 아이디어의 장단점이 무엇인지 파악되고, 새로운 아이디어가 나오게 됩니다.
물론 제가 여러분의 discussion 상대가 되겠지만, 여러분끼리의 discussion도 많으면 많을수록 좋겠습니다. 간혹 보면, 이것은 나의 일이고, 저것은 쟤가 맡은 일이라서 서로 간섭하지 않으려고 하는 경향이 있으나 그것은 결코(!) 바람직하지 않습니다. 남이 무슨 일을 하고 있는지 알아서 서로서로 도움을 주고 받을 수 있는 문화가 되었으면 좋겠습니다. 제가 weekly reports를 공개적으로 이 곳 게시판에 올리게 하는 이유도 자신이 하는 일 뿐만이 아니라 다른 사람이 무엇을 하고 있는지에 대해서도 관심을 가지게 하기 위함입니다.
실험에 대한 사전 고려
어떤 아이디어가 좋다는 것을 다른 사람에게 설득하기 위해서는 무엇이 좋아지는지 구체적인 증거를 들이밀어야 합니다. 구체적인 실험 결과가 없이 단지 말로만 이것이 저렇게 좋아진다고 하는 것은 software engineering 같은 데서는 통할지 몰라도, 우리 분야에는 통하지 않습니다. 따라서, 아이디어가 좋다고 해도, 그것을 증명할 방법을 찾지 못하면 그것은 무용지물입니다. (진짜 아이디어가 좋다면 특허는 낼 수 있습니다. 특허에는 아이디어가 좋다고 증명할 필요가 없으므로...)
결국, 적당한 실험이 뒷받침되지 않은 아이디어는 허공에 대고 메아리치는 격입니다. 이것은 바꿔 말하면, 아이디어를 발전시켜 나가는 초기부터 어떻게 실험을 해야 할지 미리미리 고려를 해야 한다는 뜻입니다. 만일, 어떤 주제에 대해서 연구를 시작할 때, 우리가 가지고 있는 infrastructure를 가지고 실험을 해 볼 수 있는 것인지를 함께 생각해 보기 바랍니다. 실제 implementation을 할 수 있겠는지, 아니면 필요한 simulator를 얻을 수 있는지, benchmark로는 무엇을 사용하면 되는지 등등에 대해서 사전 검토가 필요합니다.
이러한 점에서 저는 예전에 비해 연구 환경이 매우 나아졌다고 생각합니다. 예를 들어, 제가 학교 다닐 때에는 우리나라에서 OS나 architecture에 대해서 연구하기가 매우 힘들었습니다. OS에 관한 아이디어가 있어도 OS source code가 없으니 implement 해 볼 방법이 없었고, architecture에 관한 연구도 이와 사정이 비슷하였습니다. 그러나 이제는 Linux와 같이 source code가 가용한 OS를 이용할 수 있으니, 무언가를 해 볼 수 있는 여지가 많이 생겼습니다. 저는 Linux를 좋아하고 즐겨 사용하지만, open source니 뭐니 그런 것 보다도, 일단 연구의 중요한 도구라는 점에 의의를 두고 있습니다. 이제는 Linux 상에서 무언가를 했다고 해도 그 사실만으로는 태클을 받지 않는 정도의 수준까지 올라왔으니, 학교의 입장에서는 연구를 하는데에 굉장히 큰 도움이 되는 것은 사실입니다. Architecture에서도 요즘에는 SimpleScalar와 같은 좋은 시뮬레이터들이 많이 있어서 연구에 활용되고 있으니, 이제 실험을 못해서 논문을 쓰기 어렵다는 핑계를 대기도 힘들어 졌습니다.
어쨌거나 요약하면, 적절한 실험을 통하여 검증해 볼 수 있는 아이디어만을 일단 연구의 대상으로 하는 것이 좋겠다는 것입니다. 이렇게 하면 단지 장비나 실험 환경이 없어서 여러분의 좋은 아이디어가 사장될 지는 모릅니다. 그러나 검증할 수 없는 아이디어에 대해서 시간을 보내고 있기에는 여러분의 시간이 너무나 한정되어 있습니다. 졸업들 빨리 해야죠...
많은 사람의 관심이 되는 topic vs. 일부의 사람들만 관심있는 topic
연구 topic, 특히 박사학위 논문 topic에는 두가지가 있습니다. 하나는 아주 일부의 사람들만 관심이 있는 topic입니다. 이것은 community도 작고, 관련된 컨퍼런스나 워크샵도 수가 작습니다. 일부의 사람들만 관심이 있는 이유는 다른 사람들이 별로 중요하지 않다고 생각하거나, 현실성이 없거나, 너무 미래지향적이거나 하기 때문입니다. 다른 하나는 많은 사람들이 현재 active하게 연구하고 있는 topic입니다. 이런 분야는 많은 사람들이 달라 붙어있기 때문에 논문도 많이 발표되고 굉장히 속도가 빠르게 진행됩니다.
전자의 경우에는 사람들이 적기 때문에, 경쟁도 그리 심하지 않고, 시간적인 여유도 있고, 잘(!)만하면 비교적 쉽게 논문을 쓸 수 있을 가능성이 있습니다. 그러나 그렇게 논문을 쓴다고 해도 일부의 사람들만 인정을 할 뿐입니다. 반면, 후자의 분야는 내가 하고 있는 것을 남이 한 발 앞서 할 수도 있고, 경쟁도 매우 심하지만, 일단 그런 경쟁을 뚫고 논문을 발표하게 되면, 많은 사람들이 자신이 한 일에 대해서 관심도 갖고 국제적인 지명도도 얻게 됩니다.
두 가지 종류의 topic 중 어떤 것을 선택할 지는, 개개인의 성향입니다. 저보고 추천하라고 하면, 저는 힘들지만 후자를 선택하라고 하겠습니다. 많은 사람들이 연구하는 topic에서 일을 하는 것은 많은 시간과 노력과 때로는 좌절을 수반하지만, 그만큼 보람도 큰 법입니다. 제가 앞서 중요한 conference 들을 언급하였는데, 그러한 conference에 논문을 발표한다는 것은 여러분이 후자의 일을 하고 있다는 뜻입니다.
능동적/공격적인 연구
능동적 연구라고 함은 누가 시키지 않아도 스스로 연구를 해 나아갔으면 좋겠다는 뜻이고, 공격적인 연구라 함은 논문쓰는 것을 두려워 하지 말라는 뜻입니다.
능동적인 연구를 강조하는 이유가 교수가 논문지도 안하고 놀기 위함은 절대(!) 아닙니다. 석사건, 박사건, 졸업을 하는 것은 지도교수보다는 본인의 역량이라는 점을 명심하시기 바랍니다. 지도교수가 밥상을 차려줄 수는 있어도, 밥을 먹는 것은 본인입니다. 제가 석사 신입생들 면접할 때도 얘기를 했는데, 대학원은 제가 여러분을 귀찮게 하는 곳이 아니라, 여러분이 저를 귀찮게 하는 곳입니다. 언제라도 어떤 문제에 대해 저와 얘기하고 싶다면 제게 찾아오시기 바랍니다. 대부분 제가 잘 알지 못하는 내용이 될 가능성이 높지만서두...^^. 가끔 보면 지도교수가 옆에서 이거해 봐라, 저거해 봐라 하는 경우에는 왜 하는지도 모르고 별로 신도 나지 않은 채로 일을 하지만, 지도교수가 아무 신경도 쓰지 않으면 오히려 불안해서 스스로 연구를 하게 되는 경우가 많은 것 같습니다. 저도 여러분의 졸업과 관련하여서는 귀찮게 하지 않을 작정이니 졸업하고 싶으면 스스로 알아서 하세요.
공격적으로 연구를 하라는 것은 좋은 논문 하나에 집착하지 말라는 뜻입니다. 간혹 보면 대학원, 특히 박사과정에 들어오면 박사 논문 topic을 찾아 헤매서 돌아다니고, 그 외의 일은 신경도 쓰지 않는 것을 봅니다. 큰 거 한 방을 찾는 거죠. 하지만, 논문도 써 본 사람이 잘 쓰는 법입니다. 실제 박사논문 topic을 잡아서 집중적으로 일을 하기 전에, 작은 아이디어라도 논문으로 만들어 내어 보고, 영어 엉터리라고 reject도 당해 보고, accept 되어 다른 사람들 앞에서 영어로 발표도 해 보고 할 기회를 갖기를 바랍니다. 몇 번 해 보면, 대충 어떻게 돌아가는 건지 감도 잡히고, 실제 본 무대에서 뛸 때 도움이 됩니다. 야구 선수들도 처음에는 minor league에서 연습하다가 major league에서 뛰는 것과 마찬가지로, 작은 아이디어라도 실험 결과를 뽑고, 논문으로 만들어서 좀 떨어지는 컨퍼런스나 워크샵에라도 발표하려는 노력을 하기 바랍니다. 제가 생각하기에는 박사 1-2년차때 석사논문 내용이나, 수행한 project, course term project에서 한 일들을 가지고 major/minor conference에 한 두 개의 논문을 발표해 보고, 박사 3년차 이후에 본격적으로 자신의 topic에 대해서 연구하여 major conferences에 논문 2개 이상, 그리고 journal 논문 하나 이상 정도를 쓰고 졸업을 하면 좋겠습니다. 석사과정의 경우에도, 웬만한 conference에 실을 수 있을 정도가 되어야 석사 논문으로 적당합니다. 석사 논문을 쓰면 그것을 정리해서 conference나 정보과학회 논문지에 내어 보는 것을 권장합니다.
또 하나, 능동적/공격적인 연구와 관련하여 제가 강조하고 싶은 것은, 앞에서도 얘기했지만 절대 혼자서 모든 것을 다하려고 하지 말라는 것입니다. 좋은 아이디어가 있으면 혼자 끙끙거리지 말고, 다른 사람과 상의하고 일을 나누어서 하세요. 혼자서 논문 2개 쓰는 것보다, 둘이서 논문 4개 쓰는 것이 훨씬 쉽습니다. 그리고, 같이 일하는 사람이 후배일 경우에는 후배에게 일을 가르쳐주는 효과도 있게 되겠죠.
마지막으로, 대학원에 들어올 때는 순서대로 들어오지만, 졸업은 반드시 들어온 순서대로가 아니라는 점입니다. 때로는 선배를, 혹은 교수를 뛰어 넘어 자신의 능력을 발휘하는 여러분이 되기 바랍니다. 그리고, 석사과정에 있다 하더라도 반드시 4학기를 채워야 할 필요는 없습니다. 3학기만에 조기졸업을 할 수도 있고, 이제 석박사 통합과정이라는 것도 생겼으니 필요하면 이용하시기 바랍니다.
논문의 first author
논문을 쓸 때 주의할 점은 아이디어를 낸 사람이 반드시 first author가 되는 것은 아니라는 점입니다. First author는 기본적으로 해당 논문을 작성할 때 주도적으로 writing을 한 사람입니다. 즉, 아이디어를 A가 냈다고 하더라도, 논문을 B가 썼다면 B가 first author가 된다는 것입니다. 이것은 아이디어를 내는 것에 못지 않게 그 아이디어를 구체적으로 논문화하는 데에도 많은 시간과 노력이 들어가기 때문입니다. 그러니 아이디어내고, 실험 결과만 뽑았다고 해서 자동적으로 first author가 되는 것은 아니라는 점을 명심하시기 바랍니다. 논문의 first author가 되기 위해서는 그 논문을 실제로 본인이 작성해야 합니다.
연구는 타/이/밍
항상 computer systems에서도 resource management가 문제가 되는데, 여러분의 대학원 생활에도 자원 관리, 특히 여러분의 시간 관리가 중요합니다. 대학원, 특히 박사과정에서는 어리버리 하다 보면 시간이 금새 지나가는 수가 많습니다. 박사 1-2년차에는 랩일 하고, 코스웍 듣고 하다 보면 가고, 3년차는 뭔가 해 봐야지 하면서 보내고, 4년차가 되면 슬슬 초조해지기 시작하는데 박사논문 topic은 잘 안 잡히고, 5년차에 다행이 topic하나 잡아서 한 6개월 죽어라 일을 하고 간신히 졸업하면 다행... 인 것이 잘못하면 걷게 되는 여러분의 운명입니다.
일단 가장 문제가 되는 것은 빨리 졸업해야 되겠다는 motivation의 부재입니다. 그냥 사람들 좋고, 시간 여유 많고, 사회에 나가는 것도 두렵고, 그러다가 보면 대학원 생활에 익숙해 지고, 왜 대학원에 있는지도 모르고, 빨리 나가고 싶은 생각도 없고 그렇게 됩니다. 국내 대학원에 있는 사람과 유학간 사람들을 비교해 볼 때, 대부분 국내에서 박사학위를 하는 사람들이 상대적으로 performance가 떨어진다고들 합니다. 이것이 원래 부지런하고 자기 앞가림하는 사람들이 유학을 갔기 때문이라고 보는 사람도 있으나, 저는 기본적으로 국내에서 박사학위를 하는 대학원생들이 유학간 사람들에 비해 motivation과 긴장도가 떨어지고 열심히 하지도 않기 때문이라고 생각합니다. 제가 그래봤기 때문에 잘 압니다.
여러분이 할 일이 많다는 것은 저도 잘 아나, 대학원에 있는 동안 만이라도 일단은 연구에 우선 순위를 두었으면 하는 것이 제 바램입니다. 졸업하고도 할 수 있는 일은 대학원에 있는 동안은 잠시 미뤄두세요. 그게 싫다고요? 그러면 열심히 연구해서 빨리 졸업하고 그 다음에 하고 싶은 것 실컷 하면 되지 않습니까? 이렇게 얘기한다고 해서 매일 모니터 앞에만 앉아있으라는 말은 아닙니다. 사람이 연구만 하면서 살 수는 없으니까 가끔 기분전환도 하고 술도 마시고, 게임도 하고 그래야 되겠죠. 따라서 결국은 시간 관리를 잘 해야 하는 문제가 되는데, 제가 볼때는 생산성과 집중력이 중요합니다.
연구는 타이밍입니다. 특히 많은 사람들이 관심을 가지고 있는 topic에 대해서 일을 할 경우에는 더욱 그러합니다. 나에게 참신한 아이디어가 있더라도, 내가 어리버리하면서 시간을 보내고 있는 사이 다른 사람이 비슷한 아이디어를 발표해 버리면 내가 들인 시간은 물거품이 됩니다. 가끔 어떤 참신한 아이디어가 있으면, 저는 빨리 결과 뽑아서 논문으로 만들고 싶은데, 정작 그 일을 하는 학생은 여유를 가지고 일을 하는 바람에 제 속만 타는 경우가 있습니다. 저는 누가 먼저 발표할까봐 불안해 죽겠는데 말이죠. 따라서, 같은 일을 하더라도 1년 내내 일을 꾸준히 성실하게 하는 사람보다는, 6개월에 집중해서 끝내고 나머지 6개월을 탱자탱자 보내는 사람이 훨씬 더 낫습니다.
학자적 양심
나중에 졸업 등에 스트레스를 받게 되면 한순간 실험 결과를 조작하고 싶은 충동이나 다른 사람의 아이디어를 내 것인냥 슬쩍 빌려오는 등의 유혹을 받게 될 경우가 있는데, 이것은 무!조!건! 절!대! 안 됩니다. 왜냐고요? 바로 학자적 양심 때문입니다. 도덕적인 양심이 있듯이, 배운 사람에게는 학자적 양심이라는게 있습니다. 누가 강요하지 않아도 스스로 지켜야 할 선이 있는 거죠.
일전에 우연히 정보과학회 춘계 학술대회 논문집을 넘겨보다가, 우리 랩 학생이 말도 안 되는 논문을 낸 것을 보고 혼낸 적이 있습니다. 이미 웬만한 사람은 다 알만한 내용을, 심지어 예제 코드로도 많이 나오는 내용을 논문이랍시고 버젓이 쓴 것이 실렸기 때문입니다. 물론 정보과학회 학술대회 논문집을 살펴보면 말도 안되는 논문들이 많은 것은 사실이고, 그런 논문들이 심사 과정에서 걸러지지 않는 것도 문제이긴 합니다. 또한, 정보과학회 학술대회 논문의 경우에는 교수님들께서 일일이 신경을 쓰시지도 않고요. 그러나 그렇다고 해서 그런 논문을 실을 수는 없는 일입니다. 왜냐하면, 많은 사람들이 KAIST에서는 도대체 무슨 일을 하고 있는지 주의 깊게 살펴보고 있기 때문이죠. 여러분이 허접한 논문을 발표하면 여러분 논문 발표 실적에 한 줄 더 쓸 수는 있겠지만, KAIST나 여러분의 지도교수, 혹은 여러분 자신의 얼굴에 먹칠을 하게 되는 것입니다. 많이 배울수록, 스스로 지켜야 할 선의 수준도 높아지기 마련입니다.
KAIST의 특수성
마지막으로 여러분에게 부탁하고 싶은 점은, 특히 KAIST 학생으로서의 책임감을 가져달라는 점입니다. KAIST는 다른 학교와는 달리 많은 부분을 정부의 지원, 그러니까 국민의 세금에 의존하고 있는 학교입니다. 여러분 한명을 교육시키기 위하여 여러분의 부모님들을 포함한 얼마나 많은 사람들이 일하고 세금을 내는지 생각해 보기 바랍니다. 그렇게 여러분을 믿고 지원해 준 국민들에게 보답하기 위해서라도, 좋은 연구하고 빨리 졸업해서 사회에 보탬이 되는 일을 하는 것이 바람직합니다. 만일 여러분이 하라는 공부는 안 하고 게임하면서 하루하루를 지세운다면, 제가 보기에는 공적자금 빼돌리는 악덕 기업주와 다를 바가 없습니다.
많은 KAIST 학생들이 자신은 머리가 좋기 때문에, 아니면 여기까지 온 것도 경쟁을 뚫고 들어온 것이기 때문에 이만한 혜택을 받을 자격이 있다고 생각하는 경향이 있습니다. 그러나 사장이 되기까지 힘들었으니 이제 돈을 빼돌려도 된다는 것이 합리화되지 않는 것처럼, 여러분이 KAIST 학생이 되었다는 것이 여러분이 받고 있는 혜택을 당연하게 만드는 것은 아닙니다. 때로 여러분이 지치거나 힘들 때, 얼마나 많은 학생들이 여러분과 함께 KAIST에 들어오고 싶어 했고, 지금도 KAIST에서 공부하기를 꿈꾸면서 얼마나 많은 후배들이 공부하고 있는지 생각해 보기 바랍니다.
이것이 석사논문 주제가 되나요? (version 0.2 추가)
많은 학생들이 찾아와서는 묻습니다. "제게 이러저러한 아이디어가 있는데 이것이 석사논문 주제로 적당할까요?" 라고요. 태어날 때 천한 사람, 귀한 사람이 따로 있는 것이 아니듯이, 저는 처음부터 석사논문으로 적당한 topic이 따로 있는 것은 아니라고 생각합니다. 어떤 topic이 석사논문으로 적당한 지의 여부는 전적으로 그것을 주장하는 여러분에게 달려 있습니다. 즉, 여러분이 그것이 왜 중요하고, 어떤 점이 나아지며, 다른 사람이 한 일과는 어떻게 다른지를 논문 committee에 있는 교수님들이나 다른 사람들에게 효과적으로 설득할 수 있는지의 여부가 더욱 중요하다는 점입니다. 학위논문 심사를 보통 디펜스(defense) 한다고 하는데, 이것은 많은 사람들의 공격으로부터 자신이 한 일이 중요하다는 것을 설득시키고 지켜낼 수 있어야 하기 때문입니다.
자기의 논문을 디펜스하기 위하여 무엇보다도 중요한 것은 앞에서도 언급했듯이 다양하고 많은 사람들과의 discussion 입니다. 혼자서 생각하다보면 한쪽으로만 생각이 흐르는 경향이 있어서 중요한 것을 못보고 지나칠 가능성이 많습니다. 그러나 백그라운드가 다른 여러 사람에게 자기가 한 일을 설명하고 이해시키려고 하다 보면, 그 사람들이 이해하지 못하는 점을 설명해 주는 과정에서 놓치고 있던 것을 발견하게 되고 더 좋은 아이디어가 떠오르게 되기도 합니다. 또, 얘기를 하다 보면, 사람들이 여러가지를 물고 늘어지면서 시비를 걸게 되는데, 이런 점에 대해서 미리 대답을 생각해 보고 하면 실제 논문심사시에도 훨씬 여유가 있게 됩니다. 결국 논문심사를 위해 여러분이 준비해야 할 것은 이런 질문에는 이렇게 대답하고, 저런 질문에는 저렇게 대답하고.. 등을 미리 생각해 놓아야 하는 것인데, 당연히 예상문제를 많이 풀어보고 들어가는 것이 유리합니다. 그러니 다른 사람과의 discussion은 많으면 많을수록 좋습니다.
보통 어떤 논문에 대해서 눈여겨 보는 것은,
1. 어떤 환경 혹은 시나리오를 가정하고 있는가?
2. 가정하고 있는 환경에서 어떤 문제가 있는가?
3. 그 문제가 왜 중요한 문제인가?
4. 문제 해결을 위한 본인의 아이디어는 무엇인가?
5. 같은 문제 해결을 위해 다른 사람들이 기존에 한 일은 무엇인가?
6. 다른 사람들이 한 일과 본인이 한 일이 *객관적*이고 *정량적*으로 잘 비교, 분석되었는가?
7. 혹시 나빠지는 점은 없는가?
등등입니다. 위의 물음에 대해 자신을 가지고 다른 사람을 설득할 수 있으면 됩니다.
제 개인적으로, 석사논문의 수준은 웬만한 conference에 accept될 수 있는 정도면 적당하다고 생각합니다. 이 말은 바꿔말하면, 여러분이 작성하는 석사논문이 웬만한 conference의 심사위원들을 설득할 수 있는 정도의 수준이 되어야 한다는 뜻입니다.
세미나 참석 (version 0.2 추가)
아이디어를 얻기 위해서 또 하나 강조하고 싶은 것은 세미나 참석입니다. 보통 대학원 연구실 배정을 받고 나면 언제부터 본인에게 연구분야가 있었다고 자기 연구분야가 아니면 세미나에 흥미조차 없는 사람들이 많습니다. 그러나, 앞으로 여러분이 어떤 일을 하게 될지 모르고, 그런 기회가 아니라면 다른 분야에서 어떤 일을 하는지 조차 모르게 되니 가급적 학과/학교에서 열리는 세미나에는 시간을 내어 참석하기 바랍니다. 그 시간에 여러분이 논문을 하나 읽는 것보다, 해당 분야에 대해서 잘 정리해서 발표해 주는 세미나를 듣는 것이 훨씬 도움이 됩니다.
그리고 결국 전산학에서 어떤 문제를 풀기 위한 approach는 거의 비슷하기 때문에, 다른 사람들이 어떤 문제를 어떤 식으로 풀어나갔는지를 보는 것이 많은 도움이 됩니다. 그리고 어떤 경우에는 전혀 다른 분야에서 쓰는 방법을 내 분야에 적용시켰을 때 매우 효과적인 경우도 많습니다. 따라서, 아무리 다른 분야의 세미나라 하더라도 세미나를 들으면서 자유롭게 내가 알고 있는 분야에 비슷한 문제는 없는지 등을 생각해 보는 것이 좋습니다. 내용을 모르더라도 최소한 발표는 어떻게 하는 것이 좋겠는지, 혹은 질문에 대해 어떻게 대처해야 하는지 등에 관해서라도 배울 수 있는 이점이 있으니 세미나 참석은 중요합니다. 같은 이유로 대학원 때 수업도 본인의 연구 분야에 관련된 부분만 집중해서 듣지 말고, 다른 분야의 과목들을 듣는 것을 권장합니다.
흔히, 박사학위의 기본 요건 중의 하나가 T자형 인간이라고 합니다. 그러니까 전산학 전 분야에 대해서 breadth와 자기 분야에서의 depth를 가져야 한다는 것이죠. 보통 자격고사(qualifying exam)를 통해 breadth를 테스트 하고, depth는 박사학위논문심사에서 따지게 됩니다. 우리 학교의 경우 자격고사가 제 역할을 하고 있지 못해서 좀 문제이기는 하지만.. 아뭏든 둘 다 중요하니 자기 분야의 depth만 고집할 게 아니라, 다른 분야에서 어떤 일들이 일어나고 있는지도 관심을 가지고 살펴보기 바랍니다. 그게 다 피가 되고, 살이 됩니다.
----
쓰다 보니 조금 훈계조로 흐른 부분도 없지 않고, 일부는 몇몇 사람에게 얘기한 적도 있는데.... 정리하는 차원에서 쓴 것이니 참고하기 바랍니다. 또 다른 생각이 나면 지속적으로 업데이트 하도록 하겠습니다.
아래는 참고할 만한 링크입니다.
Useful Links on Graduate Studies, Research, and Technical Communication
Graduate School Survival Guide (by Wanda Pratt)
Guides to Surviving Computer Science Graduate School (by Ronald Azuma)
Advice on Research and Writing
Graduate Studies, Research and Careers in Computer Science
An Evaluation of the Ninth SOSP Submissions or How (and How Not) to Write a Good Systems Paper
How to Have a Bad Career in Research/Academia (Also at David Patterson's homepage)
Resources for Writers and Writing Instructors (by Jack Lynch)
임재춘의 과학기술자 글쓰기
2009년 9월 24일 목요일
DS2411
특징
DS2411은 MAXIM에서 제조하였으며, Vcc 입력 기능이 있는 실리콘 시리얼 넘버를 포함하고 있다. 제조시 레이저로 식각된 테스트를 거친 고유한 64비트 등록번호(8비트 제품코드 + 48비트 시리얼 넘버 + 8비트 CRC 테스터)를 가지며, 이들 부품이 서로 중복되지 않도록 보장한다. 1uA 미만의 대기 전류를 사용하며, 멀티드롭 컨트롤러가 내장되어 있어 공통 1-Wire 네트워크 상에서 다중 DS2411 상주가 가능하다. 8비트 제품 코드로 1-Wire 마스터에 DS2411 소자의 식별이 가능하며, 저가형 TSOC, SOT23-3 및 플립 칩 표면 실장 패키지로 마이크로프로세서의 단일 포트 핀에 직접 연결하고 최대 15.4Kbps 속도로 통신한다. 또한, 125Kbps의 통신 속도를 제공하는 오버드라이브모드를 지원한다. DS2411 소자의 동작범위는 1.5V ~ 5.25V이며, -40'C ~ +85'C에서 동작한다.
설명
DS2411 실리콘 시리얼 넘버는 외부 전원으로 동작하는 저비용 전자 등록 번호이다. DS2411은 최소의 전자 인터페이스(일반적으로 마이크로컨트롤러의 단일 포트 핀)를 통해 판별할 수 있는 절대적으로 고유한 48비트 시리얼 넘버, 8비트 CRC 및 8비트 제품 코드(01h)로 구성된다. 데이터는 Dallas Semiconductor의 1-Wire 프로토콜을 통해 직렬로 전송된다. 외부 전원은 소자의 동작 전압 범위를 일반적인 1-Wire 소자 미만으로 확대하는데 필요하다.
동작
DS2411의 등록번호는 단일 데이터 라인을 통해 엑세스 된다. Dallas 1-Wire 프로토콜을 사용하여 48비트 시리얼 넘버, 8비트 제품 코드 및 8비트 CRC가 검색된다. 이 프로토콜은 I/O 핀 상에서 버스 마스터에서 발생된 하강 에지인 지정된 타임 슬롯 동안 버스 상태와 관련하여 버스 트랜잭션을 정의한다. 모든 데이터는 최하위 비트부터 읽혀지고 쓰여진다. DS2411은 Vcc 파워 업과 초기 1-Wire 통신 사이에 tpwrp(1200us) 만큼의 지연을 필요로 한다. 이 시간 동안 소자는 존재 검출 펄스(presence-detect pulse)를 발생시킬 수 있다.
DS2411은 MAXIM에서 제조하였으며, Vcc 입력 기능이 있는 실리콘 시리얼 넘버를 포함하고 있다. 제조시 레이저로 식각된 테스트를 거친 고유한 64비트 등록번호(8비트 제품코드 + 48비트 시리얼 넘버 + 8비트 CRC 테스터)를 가지며, 이들 부품이 서로 중복되지 않도록 보장한다. 1uA 미만의 대기 전류를 사용하며, 멀티드롭 컨트롤러가 내장되어 있어 공통 1-Wire 네트워크 상에서 다중 DS2411 상주가 가능하다. 8비트 제품 코드로 1-Wire 마스터에 DS2411 소자의 식별이 가능하며, 저가형 TSOC, SOT23-3 및 플립 칩 표면 실장 패키지로 마이크로프로세서의 단일 포트 핀에 직접 연결하고 최대 15.4Kbps 속도로 통신한다. 또한, 125Kbps의 통신 속도를 제공하는 오버드라이브모드를 지원한다. DS2411 소자의 동작범위는 1.5V ~ 5.25V이며, -40'C ~ +85'C에서 동작한다.
설명
DS2411 실리콘 시리얼 넘버는 외부 전원으로 동작하는 저비용 전자 등록 번호이다. DS2411은 최소의 전자 인터페이스(일반적으로 마이크로컨트롤러의 단일 포트 핀)를 통해 판별할 수 있는 절대적으로 고유한 48비트 시리얼 넘버, 8비트 CRC 및 8비트 제품 코드(01h)로 구성된다. 데이터는 Dallas Semiconductor의 1-Wire 프로토콜을 통해 직렬로 전송된다. 외부 전원은 소자의 동작 전압 범위를 일반적인 1-Wire 소자 미만으로 확대하는데 필요하다.
동작
DS2411의 등록번호는 단일 데이터 라인을 통해 엑세스 된다. Dallas 1-Wire 프로토콜을 사용하여 48비트 시리얼 넘버, 8비트 제품 코드 및 8비트 CRC가 검색된다. 이 프로토콜은 I/O 핀 상에서 버스 마스터에서 발생된 하강 에지인 지정된 타임 슬롯 동안 버스 상태와 관련하여 버스 트랜잭션을 정의한다. 모든 데이터는 최하위 비트부터 읽혀지고 쓰여진다. DS2411은 Vcc 파워 업과 초기 1-Wire 통신 사이에 tpwrp(1200us) 만큼의 지연을 필요로 한다. 이 시간 동안 소자는 존재 검출 펄스(presence-detect pulse)를 발생시킬 수 있다.
2009년 9월 16일 수요일
SenWeaver
지역 IT특화연구소인 유비쿼터스신기술연구센터(UTRC 센터장 김희철)가 USN분야 응용소프트웨어 개발 기간을 획기적으로 단축할 수 있는 SW인 ‘센위버(SenWeaver)’ 플랫폼을 개발했다고 4일 밝혔다.
센위버 플랫폼은 센서노드 상에서 구동되는 센서 운영체제와 네트워크 프로토콜, 노드 응용개발도구, 네트워크 관리도구 등의 개발환경과 도구를 하나의 틀로 제공하는 시스템이다. 기업들이 응용소프트웨어 개발에만 집중할 수 있도록 함으로써 신뢰성 있는 센서네트워크 관련 솔루션을 개발 및 구축할 수 있게 한 제품이다.
센위버는 센서네트워크 플랫폼의 선두그룹인 카네기멜론대의 ‘나노-RK’나 하버드대학의 ‘Pixie’은 물론, 미국 아크록과 더스트 네트워크사의 플랫폼과 비교해 기술적인 우위가 있는 것으로 평가받았다.
김희철 센터장은 “이번에 개발된 센위버 플랫폼은 플랫폼 네트워크 산업인 스마트 산업의 핵심 수단이 될 것”이라며, “앞으로 기업들이 USN관련 다양한 응용소프트웨어를 개발할 수 있는 기반이 될 것”이라고 말했다.
UTRC는 지난 2006년 12월 대구대학교 내에 설립된 IT특화연구소다. 박사급 연구원 8명을 포함, 총 30여명의 전문연구원이 RFID/USN관련 연구를 진행하고 있다.
http://www.senweaver.co.kr/ 센위버
http://www.utrc.re.kr/ UTRC
센위버 플랫폼은 센서노드 상에서 구동되는 센서 운영체제와 네트워크 프로토콜, 노드 응용개발도구, 네트워크 관리도구 등의 개발환경과 도구를 하나의 틀로 제공하는 시스템이다. 기업들이 응용소프트웨어 개발에만 집중할 수 있도록 함으로써 신뢰성 있는 센서네트워크 관련 솔루션을 개발 및 구축할 수 있게 한 제품이다.
센위버는 센서네트워크 플랫폼의 선두그룹인 카네기멜론대의 ‘나노-RK’나 하버드대학의 ‘Pixie’은 물론, 미국 아크록과 더스트 네트워크사의 플랫폼과 비교해 기술적인 우위가 있는 것으로 평가받았다.
김희철 센터장은 “이번에 개발된 센위버 플랫폼은 플랫폼 네트워크 산업인 스마트 산업의 핵심 수단이 될 것”이라며, “앞으로 기업들이 USN관련 다양한 응용소프트웨어를 개발할 수 있는 기반이 될 것”이라고 말했다.
UTRC는 지난 2006년 12월 대구대학교 내에 설립된 IT특화연구소다. 박사급 연구원 8명을 포함, 총 30여명의 전문연구원이 RFID/USN관련 연구를 진행하고 있다.
http://www.senweaver.co.kr/ 센위버
http://www.utrc.re.kr/ UTRC
- 09.08.05 etnews -
2009년 9월 6일 일요일
Effective Link Abstraction for Wireless Sensor Networks
1. Message Pool. The message pool has been invaluable for storing messages until a later point in time that they can be sent. It decouples the power management policy from the data transmission policy, which in turn means you can submit a message whenever you want and it will go out on the radio.
2. Message Futures. Due to the decoupling above, message futures are necessary if you generate more than one message per power cycle. Keeping a queue (we use cqueue by Cory Sharp) in the networking protocols allows each protocol to decide how deep the queue is and how to prioritize it. This can also be accomplished with a buffer pool that network protocols share and extract buffers when needed.
3. Neighbor Table. Moteiv doesn't use the Neighbor Table for storing link estimates, instead we've found its usefulness in maintaining power schedules. The neighbor table makes it easy for the link to either insert schedule or the network protocol (such as NetSync and NetWake in Boomerang) to add other schedules.
One shortcoming--We will be changing the interface to comply more with TEP102 for timers. Currently the neighbor table takes a 32-bit absolute time for turning the radio on and off. Because TinyOS is not real-time, delays can cause an event to be missed, and lead to 36-hour delays (32-bit rollover)! The solution is the TEP102 proposal for Alarms--use t0 and dt to specify the next wakeup interval. This then couples nicely with the Timer/Alarm system and makes the overall implementation easier.
4. Link Estimation turns out to be a bit of bust because you can't do it very well in an application-independent manner. Jack Stankovic pointed out at one of our meetings that different applications have different opinions on what a high-quality link is. Cost-based routing is one thing, but geographic or sensor-based routing has different requirements. Link estimation in the base case doesn't have to be fancy, nor does it have to give me "real units" like dBm or PER, relative link estimates are just fine for all the protocols we've encountered.
5. Reliability. I don't care how you implement reliable transport at the link, but you need to give protocols the option to ask for reliability and get feedback as to whether the reliability was achieved. This point should be obvious, but it is absolutely critical for us to have bi-directional reliability data to make informed decisions about what to do with the next message.
6. Timestamping. I've never figured out why Timestamping is not a core piece of metadata available with each packet in the default implementations of TinyOS. It is trivial to provide a timestamp either on an SFD, or when SFD isn't available, on the packet dispatch. Sure, it won't be 100% accurate, but with a 30.5us clock it doesn't really matter. The #1 best addition to SP in Boomerang was timestamping, and has served us very well.
7. Naming. This is an overrated topic. We initially thought we were going to implement Arsalan's SP handle idea, where each link address is given a virtual handle for network protocols to use to decouple the link address (size, interface, type, etc) from the network decisions.. Then we starting looking at the realities of the situation and decided that, in practice, it was never going to be needed and could easily be pulled in if we needed it at a later date. There was no point confusing users with a handle when they're still trying to figure out what "address" means.
8. Congestion. Clearly this isn't completely important from a practical perspective. From a research/academic perspective it was quite fascinating to see we could build some congestion control schemes that had basic working properties in a platform/link independent manner. I still am fascinated by that, but practically speaking--our motes are off most of the time and our goal is to do as little data transfer as possible, so 99.9999% of the time there is no congestion.
9. Phase/Delay feedback. Not necessary with the message pool decoupling transmission from the network protocols. David Culler and I initially thought that this was a requirement for the decoupling, but experience with SP has shown that the message pool can do an effective job of the decoupling without complicating the other protocols with additional phase/delay feedback.
10. Urgent. I think this is somewhat useful and doesn't need to have more than 1-bit of information. There's a number of papers out there, including one from Stankovic, that talk about how 1-bit of information can provide effective prioritization of network traffic. Arbitrary numbers of priority levels, in my opinion, are complex and aren't required by any existing protocols. The wireless sensor system is supposed to work together--if you are worried about resource constrained systems fighting internally with themselves, you're probably developing your application incorrectly.
11. Abstract data types. The initial version of SP required you to specify the fields in the message structure itself by directly accessing them. Phil Levis was right in complaining that it led to a lot of programmer error. In SP in Boomerang, we moved to a system where we explicitly prohibited users from editing any of the fields of an sp_message_t structure. Instead, you set fields using the SPSend.send() and SPSend.sendAdv() commands, and access fields through the SPMessage interface of SPC. This is a much safer implementation and has reduced the number of headaches that we encountered in the initial implementation of SP for the Sensys paper.
12. Receive. We completely threw out the TinyOS method of Receive where you must return a message pointer and we introduced a new interface, SPReceive, that can fan out to as many protocols as you need. This has been a time and bug saving development. The notion is the following: If you need data in the received message, you must copy or do something with it before returning from the SPReceive.receive() function. The buffer passing mechanism of ReceiveMsg in the main TinyOS distribution, although novel in principle, just wasn't used in practice.
2. Message Futures. Due to the decoupling above, message futures are necessary if you generate more than one message per power cycle. Keeping a queue (we use cqueue by Cory Sharp) in the networking protocols allows each protocol to decide how deep the queue is and how to prioritize it. This can also be accomplished with a buffer pool that network protocols share and extract buffers when needed.
3. Neighbor Table. Moteiv doesn't use the Neighbor Table for storing link estimates, instead we've found its usefulness in maintaining power schedules. The neighbor table makes it easy for the link to either insert schedule or the network protocol (such as NetSync and NetWake in Boomerang) to add other schedules.
One shortcoming--We will be changing the interface to comply more with TEP102 for timers. Currently the neighbor table takes a 32-bit absolute time for turning the radio on and off. Because TinyOS is not real-time, delays can cause an event to be missed, and lead to 36-hour delays (32-bit rollover)! The solution is the TEP102 proposal for Alarms--use t0 and dt to specify the next wakeup interval. This then couples nicely with the Timer/Alarm system and makes the overall implementation easier.
4. Link Estimation turns out to be a bit of bust because you can't do it very well in an application-independent manner. Jack Stankovic pointed out at one of our meetings that different applications have different opinions on what a high-quality link is. Cost-based routing is one thing, but geographic or sensor-based routing has different requirements. Link estimation in the base case doesn't have to be fancy, nor does it have to give me "real units" like dBm or PER, relative link estimates are just fine for all the protocols we've encountered.
5. Reliability. I don't care how you implement reliable transport at the link, but you need to give protocols the option to ask for reliability and get feedback as to whether the reliability was achieved. This point should be obvious, but it is absolutely critical for us to have bi-directional reliability data to make informed decisions about what to do with the next message.
6. Timestamping. I've never figured out why Timestamping is not a core piece of metadata available with each packet in the default implementations of TinyOS. It is trivial to provide a timestamp either on an SFD, or when SFD isn't available, on the packet dispatch. Sure, it won't be 100% accurate, but with a 30.5us clock it doesn't really matter. The #1 best addition to SP in Boomerang was timestamping, and has served us very well.
7. Naming. This is an overrated topic. We initially thought we were going to implement Arsalan's SP handle idea, where each link address is given a virtual handle for network protocols to use to decouple the link address (size, interface, type, etc) from the network decisions.. Then we starting looking at the realities of the situation and decided that, in practice, it was never going to be needed and could easily be pulled in if we needed it at a later date. There was no point confusing users with a handle when they're still trying to figure out what "address" means.
8. Congestion. Clearly this isn't completely important from a practical perspective. From a research/academic perspective it was quite fascinating to see we could build some congestion control schemes that had basic working properties in a platform/link independent manner. I still am fascinated by that, but practically speaking--our motes are off most of the time and our goal is to do as little data transfer as possible, so 99.9999% of the time there is no congestion.
9. Phase/Delay feedback. Not necessary with the message pool decoupling transmission from the network protocols. David Culler and I initially thought that this was a requirement for the decoupling, but experience with SP has shown that the message pool can do an effective job of the decoupling without complicating the other protocols with additional phase/delay feedback.
10. Urgent. I think this is somewhat useful and doesn't need to have more than 1-bit of information. There's a number of papers out there, including one from Stankovic, that talk about how 1-bit of information can provide effective prioritization of network traffic. Arbitrary numbers of priority levels, in my opinion, are complex and aren't required by any existing protocols. The wireless sensor system is supposed to work together--if you are worried about resource constrained systems fighting internally with themselves, you're probably developing your application incorrectly.
11. Abstract data types. The initial version of SP required you to specify the fields in the message structure itself by directly accessing them. Phil Levis was right in complaining that it led to a lot of programmer error. In SP in Boomerang, we moved to a system where we explicitly prohibited users from editing any of the fields of an sp_message_t structure. Instead, you set fields using the SPSend.send() and SPSend.sendAdv() commands, and access fields through the SPMessage interface of SPC. This is a much safer implementation and has reduced the number of headaches that we encountered in the initial implementation of SP for the Sensys paper.
12. Receive. We completely threw out the TinyOS method of Receive where you must return a message pointer and we introduced a new interface, SPReceive, that can fan out to as many protocols as you need. This has been a time and bug saving development. The notion is the following: If you need data in the received message, you must copy or do something with it before returning from the SPReceive.receive() function. The buffer passing mechanism of ReceiveMsg in the main TinyOS distribution, although novel in principle, just wasn't used in practice.
- Joe Polastre -
2009년 9월 2일 수요일
2009년 8월 30일 일요일
Synchronized Low-power Protocol
동기 방식 저전력 프로토콜은 멀티홉 네트워크에서 time sync를 유지하면서 active/sleep 스케줄링을 하도록 설계되어 있다.
32KHz로 동작하는 자신의 타이머를 이용하여 time stamp를 얻고, 자신의 시간 정보를 broadcasting한다. 시간 정보를 담고 있는 sync 메시지를 받은 노드들은 자신의 시간 정보와 수신된 시간 정보를 비교하여 업데이트한다.
다음의 원문은 주기를 이용한 duty cycle 적용 방법이다.
Boomerang lowpower works upon the principle of synchronised global time known to all motes in the network. All synchronised motes then go to sleep and wake up at the same time (duty cycle). All messages are sent/received within this duty cycle. Messages queued to sending outside this time are simply buffered until the next duty cycle.
In Boomerang this is managed by 2 components, netSync which handles global time and netWake which handles the wake/sleep mechanism.
If you have access to a Boomerang environment, run the Trawler application compiled for lowpower. There you can see that messages may arrive at an inconsistent rate, but they all arrive eventually.
Boomerang allows you to change the duty cycle via the lowpower parameter of make.
The NETSYNC_PERIOD_LOG2 macro allows you to change the time between listening periods
by default NETSYNC_PERIOD_LOG2 is 16 i.e. 2**16 ticks of the 32khz clock is 2 seconds. Default lowpower is 5% .
5% of 2 seconds is 100msecs. So by default you listen for 100msecs every 2 seconds.
Suppose I want 100sec every 4 seconds, set NETSYNC_PERIOD_LOG2 to 17 ( 4 seconds) and lowpower to 3 (3% of 4 seconds = 120msec)
Add the following line to your makefile
ifeq ($(filter netsync_period_log2,$(MAKECMDGOALS)),netsync_period_log2)
then do
makelowpower,3 netsync_period_log2,17
32KHz로 동작하는 자신의 타이머를 이용하여 time stamp를 얻고, 자신의 시간 정보를 broadcasting한다. 시간 정보를 담고 있는 sync 메시지를 받은 노드들은 자신의 시간 정보와 수신된 시간 정보를 비교하여 업데이트한다.
- routing message : minimum cost를 계산하여 route-path를 설정하기 위한 메시지
- sync message : 시간 동기화를 위한 메시지로 자신의 시간 정보를 브로드캐스팅
- period : active/sleep 주기를 설정
- duty cycle : 한 주기 동안 동작 가능한 비율
다음의 원문은 주기를 이용한 duty cycle 적용 방법이다.
Boomerang lowpower works upon the principle of synchronised global time known to all motes in the network. All synchronised motes then go to sleep and wake up at the same time (duty cycle). All messages are sent/received within this duty cycle. Messages queued to sending outside this time are simply buffered until the next duty cycle.
In Boomerang this is managed by 2 components, netSync which handles global time and netWake which handles the wake/sleep mechanism.
If you have access to a Boomerang environment, run the Trawler application compiled for lowpower. There you can see that messages may arrive at an inconsistent rate, but they all arrive eventually.
Boomerang allows you to change the duty cycle via the lowpower parameter of make.
The NETSYNC_PERIOD_LOG2 macro allows you to change the time between listening periods
by default NETSYNC_PERIOD_LOG2 is 16 i.e. 2**16 ticks of the 32khz clock is 2 seconds. Default lowpower is 5% .
5% of 2 seconds is 100msecs. So by default you listen for 100msecs every 2 seconds.
Suppose I want 100sec every 4 seconds, set NETSYNC_PERIOD_LOG2 to 17 ( 4 seconds) and lowpower to 3 (3% of 4 seconds = 120msec)
Add the following line to your makefile
ifeq ($(filter netsync_period_log2,$(MAKECMDGOALS)),netsync_period_log2)
then do
make
2009년 8월 27일 목요일
xubuntu에서 압축 해제
tar 압축 파일 중 노틸러스에서 자동으로 압축이 풀리지 않는 파일이 간혹 있다.
이 경우 터미널을 이용하여 압축을 해제하면 된다.
tar로 생성된 파일은
# tar xvf
tgz나 tar.gz는
# tar xvfz
와 같이 하면 된다.
이 경우 터미널을 이용하여 압축을 해제하면 된다.
tar로 생성된 파일은
# tar xvf
tgz나 tar.gz는
# tar xvfz
와 같이 하면 된다.
2009년 8월 26일 수요일
MAC ack & retransmission
retransmission 기능을 사용할 때는 AMPromiscuous + Queue 조합을 사용하는데, 1hop adhoc mode의 경우는 이것이 불필요할 뿐더러 programmer-controllable하지 않은 부분이 추가되는 단점이 있음. 따라서 AMStandard component를 사용하면서 retransmission을 적용하는 것이 필요하다.
reliability를 높이기 위해 retransmission 기능을 사용하고자 할 때는 다음과 같이 설정한다.
0. 설정
1. Application에서 MacControl Component를 wiring
configuration Test {
}
implementation {
component CC2420RadioC;
...
TestM.MacControl -> CC2420RadioC;
}
2. StdControl.start() 에 MacControl.enableAck() 을 추가
module TestM {
provides {
...
}
uses {
interface MacControl;
...
}
implementation {
...
command result_t StdControl.start() {
call MacControl.enableAck();
}
...
}
3. tos/lib/CC2420Radio/CC2420RadioM.nc
event result_t SerialSendMsg.sendDone[uint8_t id](TOS_MsgPtr msg, result_t success) {
...
if (!retransmit \\ msg->ack != 0 \\ msgqueue[dequeue_next].address == TOS_UART_ADDR) {
// 재전송이 필요 없는 경우 큐의 포인터를 다음 패킷으로 이동시키고,
// 상위 컴포넌트로 메시지 전송 성공 이벤트 발생 (signal, SUCCESS)
...
} else {
...
if ((++(msgqueue[dequeue_next].xmit_count) > MAX_RETRANSMIT_COUNT)) {
// 최대 재전송횟수를 초과했을 경우 큐의 포인터를 다음 패킷으로 이동시키고,
// 상위 컴포넌트로 메시지 전송 실패 이벤트 발생 (signal, FAIL)
...
}
}
// 데이터 전송 Task 실행
post QueueServiceTask();
return SUCCESS;
}
테스트는 멀티홉 라우팅 기능을 사용하며, 라우팅 경로를 빨리 설정하기 위해 라우팅 메시지 전송 주기를 짧게 설정하였다. 그리고 모트 3개 정도에 프로그램을 올리고 테스트 한 결과 재전송이 계속 발생하지만 Base Node에 패킷이 수신되지 않는 현상이 발생하였다. 문제의 원인을 파악한 결과, 라우팅 메시지는 Broadcast 를 사용하며 Broadcast도 이 QueuedSend 의 큐를 통해 전송이 일어나고, Broadcast에 대해서도 재전송을 수행하기 때문이었다.
따라서 위 소스를 그대로 사용하여 재전송 기능을 사용할 경우, Broadcast 하는 패킷에 대한 Ack 가 없을 경우에도 계속 재전송을 하게 되어 Breadcast가 많을 경우 Queue Overflow가 발생할 수 있으며, 쓸데 없이 계속 재전송을 수행하게 된다.
(※ 수신 노드에서는 unicast 일 경우에만 ack 메시지를 전송한다)
이 문제를 해결하기 위해서 위 소스의 if 문 조건을 다음과 같이 변경하여야 한다.
if ((!retransmit) \\ (msg->ack != 0) \\ (msgqueue[dequeue_next].address == TOS_UART_ADDR) \\ (msgqueue[dequeue_next].address == TOS_BCAST_ADDR)) {
...
}
reliability를 높이기 위해 retransmission 기능을 사용하고자 할 때는 다음과 같이 설정한다.
0. 설정
- /opt/tinyos-1.x/tos/lib/CC2420Radio/CC2420RadioM.nc에서 bAckEnable = TRUE;로 설정
- /tos/system/AMPromiscuous.nc에서 crc_check = TRUE;로 설정
- /tos/lib/Queue/QueueSendM.nc에서 retransmit = TRUE;로 설정
1. Application에서 MacControl Component를 wiring
configuration Test {
}
implementation {
component CC2420RadioC;
...
TestM.MacControl -> CC2420RadioC;
}
2. StdControl.start() 에 MacControl.enableAck() 을 추가
module TestM {
provides {
...
}
uses {
interface MacControl;
...
}
implementation {
...
command result_t StdControl.start() {
call MacControl.enableAck();
}
...
}
3. tos/lib/CC2420Radio/CC2420RadioM.nc
- BackoffTimerJiffy.fired() 에서 case TIMER_ACK 의 if (!post PacketSent()) 를 주석처리. 이것 때문에 ACK이 오지 않더라도 ack timeout 시 sendDone에 SUCCESS가 return된다.
- sendDone event callback에서 success == FAIL 인 경우 바로 msg ptr을 retransmission. 필요에 따라 retransmission counter를 두고 max_retransmission을 초과할 경우 drop
- opt/tinyos-1.x/lib/Queue/QueuedSendM.nc 는 TinyOS의 메시지 전송 큐를 관리한다. 재전송 기능도 QueuedSendM 에서 수행된다.
event result_t SerialSendMsg.sendDone[uint8_t id](TOS_MsgPtr msg, result_t success) {
...
if (!retransmit \\ msg->ack != 0 \\ msgqueue[dequeue_next].address == TOS_UART_ADDR) {
// 재전송이 필요 없는 경우 큐의 포인터를 다음 패킷으로 이동시키고,
// 상위 컴포넌트로 메시지 전송 성공 이벤트 발생 (signal, SUCCESS)
...
} else {
...
if ((++(msgqueue[dequeue_next].xmit_count) > MAX_RETRANSMIT_COUNT)) {
// 최대 재전송횟수를 초과했을 경우 큐의 포인터를 다음 패킷으로 이동시키고,
// 상위 컴포넌트로 메시지 전송 실패 이벤트 발생 (signal, FAIL)
...
}
}
// 데이터 전송 Task 실행
post QueueServiceTask();
return SUCCESS;
}
테스트는 멀티홉 라우팅 기능을 사용하며, 라우팅 경로를 빨리 설정하기 위해 라우팅 메시지 전송 주기를 짧게 설정하였다. 그리고 모트 3개 정도에 프로그램을 올리고 테스트 한 결과 재전송이 계속 발생하지만 Base Node에 패킷이 수신되지 않는 현상이 발생하였다. 문제의 원인을 파악한 결과, 라우팅 메시지는 Broadcast 를 사용하며 Broadcast도 이 QueuedSend 의 큐를 통해 전송이 일어나고, Broadcast에 대해서도 재전송을 수행하기 때문이었다.
따라서 위 소스를 그대로 사용하여 재전송 기능을 사용할 경우, Broadcast 하는 패킷에 대한 Ack 가 없을 경우에도 계속 재전송을 하게 되어 Breadcast가 많을 경우 Queue Overflow가 발생할 수 있으며, 쓸데 없이 계속 재전송을 수행하게 된다.
(※ 수신 노드에서는 unicast 일 경우에만 ack 메시지를 전송한다)
이 문제를 해결하기 위해서 위 소스의 if 문 조건을 다음과 같이 변경하여야 한다.
if ((!retransmit) \\ (msg->ack != 0) \\ (msgqueue[dequeue_next].address == TOS_UART_ADDR) \\ (msgqueue[dequeue_next].address == TOS_BCAST_ADDR)) {
...
}
2009년 8월 25일 화요일
Packet Loss...
telosb 계열의 모트에서 사용되는 라디오 모듈인 CC2420 RF Chip은 802.15.4 규격에 의해 2.4GHz 대역에서 250Kbps의 최대 통신 속도를 가진다. 그러나 이는 통신(전파) 환경이 깨끗한 상태에서의 1:1 통신의 경우에 해당된다. tinyos는 기본적으로 csma/ca방식을 사용하여, 현재 RF채널이 사용되고 있는지 확인 후 없으면 얼마의 시간지연 후에 데이터를 전송하게 된다.
예를 들어, 100 bytes의 데이터를 전송하는데 약 3 ms의 시간이 걸리는데, 데이터 전송 전에 필요한 Random Backoff 시간과 RF와 CPU간의 통신 및 레지스터 설정 등의 시간을 고려할 경우 약 5ms 정도의 전송 시간이 필요한 것이다.
멀티홉으로 통신하는 경우에는 센서 노드가 서로에게 영향을 줄 수 있다. 즉, 시간 지연이나 패킷 손실을 일으킬 수 있다. 특히 중간단에 위치한 노드들은 말단에 위치한 노드들이 보내는 패킷을 모두 수신하고, 이를 또 상위 노드에 전송하므로 여기에서 손실이 발생할 가능성이 매우 크다. 또한, Radio의 경우와는 다르게 UART의 손실이 발생할 가능성도 있다. UART의 통신 속도등이 패킷 손실을 불러올 수도 있다.
http://www.ee.kth.se/php/modules/publications/reports/2005/2284.pdf http://www.cs.berkeley.edu/~arsalan/Papers/PacketDelivery_Poster.pdf
예를 들어, 100 bytes의 데이터를 전송하는데 약 3 ms의 시간이 걸리는데, 데이터 전송 전에 필요한 Random Backoff 시간과 RF와 CPU간의 통신 및 레지스터 설정 등의 시간을 고려할 경우 약 5ms 정도의 전송 시간이 필요한 것이다.
멀티홉으로 통신하는 경우에는 센서 노드가 서로에게 영향을 줄 수 있다. 즉, 시간 지연이나 패킷 손실을 일으킬 수 있다. 특히 중간단에 위치한 노드들은 말단에 위치한 노드들이 보내는 패킷을 모두 수신하고, 이를 또 상위 노드에 전송하므로 여기에서 손실이 발생할 가능성이 매우 크다. 또한, Radio의 경우와는 다르게 UART의 손실이 발생할 가능성도 있다. UART의 통신 속도등이 패킷 손실을 불러올 수도 있다.
http://www.ee.kth.se/php/modules/publications/reports/2005/2284.pdf http://www.cs.berkeley.edu/~arsalan/Papers/PacketDelivery_Poster.pdf
T1에서의 ADC Mapping
ADC를 사용할 때 주요 인자가 2가지가 있다.
reference 전압과 resolution 이다. mica 시리즈에서 사용되는 atmega128L의 경우 보통 reference 2.56V, resolution은 10bit를 사용하는데, telos 계열에 사용되는 msp430의 경우 reference 1.5 or 2.5V, resolution은 12bit를 사용한다. 따라서 mica 계열로 했을 때와 telos 계열로 했을 때의 ADC에서 읽히는 Raw값에 대한 전압계산식은 다르다.
다음은 ADC를 매핑하는 예이다.
ADCC 컴포넌트를 사용하여 ADCControl 인터페이스와 bindPort 커맨드를 이용한다.
========================================================================
** Test.h **
#include "MSP430ADC12.h"
enum {
TOS_ADC_TEST_PORT = unique("ADCPort"),
TOSH_ACTUAL_ADC_TEST_PORT = ASSOCIATE_ADC_CHANNEL ( INPUT_CHANNEL_A0, REFERENCE_VREFplus_AVss, REFVOLT_LEVEL_2_5),};
#define MSP430ADC12_Test ADC12_SETTINGS( \ INPUT_CHANNEL_A0, REFERENCE_VREFplus_AVss, SAMPLE_HOLD_4_CYCLES, \ SHT_SOURCE_ACLK, SHT_CLOCK_DIV_1, SAMPCON_SOURCE_SMCLK, \ SAMPCON_CLOCK_DIV_1, REFVOLT_LEVEL_1_5)
** Test.nc **
configuration Test {
}
implementation {
components Main, TestM, ADCC;
Main.StdControl -> TestM;
TestM.ADC -> ADCC.ADC[TOS_ADC_TEST_PORT];
TestM.ADCControl -> ADCC;
}
** TestM.nc **
module TestM {
provides interface StdControl;
uses interface ADC;
uses interface ADCControl;
}
implementation {
command result_t StdControl.init() {
call ADCControl.init();
call ADCControl.bindPort(TOS_ADC_TEST_PORT, TOSH_ACTUAL_ADC_TEST_PORT);
return SUCCESS;
}
.....
}
reference 전압과 resolution 이다. mica 시리즈에서 사용되는 atmega128L의 경우 보통 reference 2.56V, resolution은 10bit를 사용하는데, telos 계열에 사용되는 msp430의 경우 reference 1.5 or 2.5V, resolution은 12bit를 사용한다. 따라서 mica 계열로 했을 때와 telos 계열로 했을 때의 ADC에서 읽히는 Raw값에 대한 전압계산식은 다르다.
다음은 ADC를 매핑하는 예이다.
ADCC 컴포넌트를 사용하여 ADCControl 인터페이스와 bindPort 커맨드를 이용한다.
========================================================================
** Test.h **
#include "MSP430ADC12.h"
enum {
TOS_ADC_TEST_PORT = unique("ADCPort"),
TOSH_ACTUAL_ADC_TEST_PORT = ASSOCIATE_ADC_CHANNEL ( INPUT_CHANNEL_A0, REFERENCE_VREFplus_AVss, REFVOLT_LEVEL_2_5),};
#define MSP430ADC12_Test ADC12_SETTINGS( \ INPUT_CHANNEL_A0, REFERENCE_VREFplus_AVss, SAMPLE_HOLD_4_CYCLES, \ SHT_SOURCE_ACLK, SHT_CLOCK_DIV_1, SAMPCON_SOURCE_SMCLK, \ SAMPCON_CLOCK_DIV_1, REFVOLT_LEVEL_1_5)
** Test.nc **
configuration Test {
}
implementation {
components Main, TestM, ADCC;
Main.StdControl -> TestM;
TestM.ADC -> ADCC.ADC[TOS_ADC_TEST_PORT];
TestM.ADCControl -> ADCC;
}
** TestM.nc **
module TestM {
provides interface StdControl;
uses interface ADC;
uses interface ADCControl;
}
implementation {
command result_t StdControl.init() {
call ADCControl.init();
call ADCControl.bindPort(TOS_ADC_TEST_PORT, TOSH_ACTUAL_ADC_TEST_PORT);
return SUCCESS;
}
.....
}
zigbee & tinyos
제목대로 둘의 관계는 본질적으로 다른데 웹을 뒤적거리다 보면 터무니 없는 이야기가 많아서 자칫 헷갈리기 쉽다.
그래서 이 둘을 파헤쳐 본다.
이 둘의 관계를 좀 더 명확히 하자면 IEEE 802.15.4 (PHY와 MAC) 표준에 zigbee를 사용하는지 tinyos를 사용하는지가 다르다면 다르다.
먼저 zigbee와 IEEE 802.15.4의 관계를 보자.
zigbee 표준 = IEEE 802.15.4 + zigbee spec
IEEE 802.15.4 = PHY + MAC
zigbee spec = NWK + APS + (security, ZDO)
그렇다면 tinyos는
tinyos = IEEE 802.15.4 + tinyos
IEEE 802.15.4 = PHY + MAC
tinyos = OS + (MAC) + APS
위와 같이 구성된다.
그래서 이 둘을 파헤쳐 본다.
이 둘의 관계를 좀 더 명확히 하자면 IEEE 802.15.4 (PHY와 MAC) 표준에 zigbee를 사용하는지 tinyos를 사용하는지가 다르다면 다르다.
먼저 zigbee와 IEEE 802.15.4의 관계를 보자.
zigbee 표준 = IEEE 802.15.4 + zigbee spec
IEEE 802.15.4 = PHY + MAC
zigbee spec = NWK + APS + (security, ZDO)
그렇다면 tinyos는
tinyos = IEEE 802.15.4 + tinyos
IEEE 802.15.4 = PHY + MAC
tinyos = OS + (MAC) + APS
위와 같이 구성된다.
2009년 8월 24일 월요일
Node ID
식별 가능한 Node ID는 0~65565 까지 지정해서 사용이 가능하며, 보통 0번은 베이스 노드로 사용한다.
보통 센서 노드의 ID를 부여하는 방법은, 인스톨할 때 뒤에 숫자를 붙여서 노드 ID를 부여한다. 그러나 이것은 어디까지나 임시적인 방법이다. 즉, 다른 노드들도 같은 ID를 가질수가 있기 때문이다. 이런 것을 Short Address 라고 해서 RF통신상에 트래픽을 줄이기 위해 사용한다. IEEE 802.15.4에서는 이 Short Address 외에 64bit의 고유주소를 사용한다. (EUI64) 비슷한 예로, 보통 인터넷에서 IP주소 외에 실제적으로 통신하기 위해 쓰이는 NIC 고유주소가 있는데, (이것도 MAC주소 혹은 번호라고 보통 칭한다.) 그것은 그 네트워크장치가 다른 어떤 장치와도 같지 않음을 보장해야 한다. 그래서 IEEE에서 일정부분의 일련번호를 받은 제조회사가 그 나머지 부분에 대해 겹치지 않도록 하여 제품 생산시에 기록하게 된다. 센서네트워크에서도 64bit의 주소를 용하는데 그 중 앞의 24bit는 IEEE에서 부여받은 번호를 나머지 40bit는 제조회사가 겹치지 않도록 부여 한다. 모트의 경우, 보통 이러한 40bit에 대해 제조사가 일일이 번호를 부여하기 어려우므로, DS2411과 같이 고유의 ID를 가진 칩을 사용하여 이 칩이 가지고 있는 일련번호와 제조회사과 부여받은 번호를 합쳐서 사용하게 되는데 이를 이용하면 된다. 하지만 현재 센서 네트워크 시장규모나, 성장의 규모로 볼 때, 아직 이러한 고유번호들은 사용이 미흡한 상태이다.
보통 센서 노드의 ID를 부여하는 방법은, 인스톨할 때 뒤에 숫자를 붙여서 노드 ID를 부여한다. 그러나 이것은 어디까지나 임시적인 방법이다. 즉, 다른 노드들도 같은 ID를 가질수가 있기 때문이다. 이런 것을 Short Address 라고 해서 RF통신상에 트래픽을 줄이기 위해 사용한다. IEEE 802.15.4에서는 이 Short Address 외에 64bit의 고유주소를 사용한다. (EUI64) 비슷한 예로, 보통 인터넷에서 IP주소 외에 실제적으로 통신하기 위해 쓰이는 NIC 고유주소가 있는데, (이것도 MAC주소 혹은 번호라고 보통 칭한다.) 그것은 그 네트워크장치가 다른 어떤 장치와도 같지 않음을 보장해야 한다. 그래서 IEEE에서 일정부분의 일련번호를 받은 제조회사가 그 나머지 부분에 대해 겹치지 않도록 하여 제품 생산시에 기록하게 된다. 센서네트워크에서도 64bit의 주소를 용하는데 그 중 앞의 24bit는 IEEE에서 부여받은 번호를 나머지 40bit는 제조회사가 겹치지 않도록 부여 한다. 모트의 경우, 보통 이러한 40bit에 대해 제조사가 일일이 번호를 부여하기 어려우므로, DS2411과 같이 고유의 ID를 가진 칩을 사용하여 이 칩이 가지고 있는 일련번호와 제조회사과 부여받은 번호를 합쳐서 사용하게 되는데 이를 이용하면 된다. 하지만 현재 센서 네트워크 시장규모나, 성장의 규모로 볼 때, 아직 이러한 고유번호들은 사용이 미흡한 상태이다.
- maxfor -
atomic
NesC에 자주 볼 수 있는 키워드 중에 atomic 이 있다.
atomic은 race condition을 막기 위해 존재한다.
race condition이란, 인터럽트에 의해서 발생하는
비동기적 코드들이 갑작스럽게 사용중인 전역변수에
접근하는 일이 발생했을때 일어나는 충돌을 말한다.
해결방법은 다음과 같다.
- 전역변수를 사용하지 않는다.
- 인터럽트를 사용하지 않는다.
- 되도록이면 코드를 짧게 구성한다.
- atomic키워드를 사용한다.
여기서 atomic코드는 모든 전역변수의 값을
정의할때,
atomic {
var1 = var1 + 1;
var2 = var2 -1;
}
이렇게 하게 되면, 만약 이 데이터를
처리 도중에 다른 인터럽트가 발생한다고 해도 이 데이터에
대한 선점권이 넘어가지 않으므로, 충돌은 일어나지 않게 된다.
2009년 8월 21일 금요일
Timer에 대한 진실(?) 혹은 거짓(?)
타이머가 매 3분 마다 호출되어도 매번 데이터를 전송하지는 않는다. 이는 통신 과정 중간에 task처리 과정과 rf 전송을 위해 경합하는 과정도 있기 때문에 고정된 시간에 데이터를 전송하는 것은 어렵다.
[TIP]
1024ms = 1 second
60 second * 1024ms = 61440ms(1 minute)
3600 second * 1024ms = 1 hour
[TIP]
1024ms = 1 second
60 second * 1024ms = 61440ms(1 minute)
3600 second * 1024ms = 1 hour
2009년 8월 18일 화요일
How to convert RSSI value to dBm?
Convert the unsigned raw counts (x) to a signed integer (y).
If x < 127; y = x
If x > 127; y = x - 256
Convert the signed counts (y) to RSSI in dBm, subtract -45 dBm
RSSI = y – 45 dBm
Example:
Raw Counts = 217
Convert to signed integer : 217 – 256 = -39
Calculate RSSI (dBm) : -39 – 45 = -84 dBm
If x < 127; y = x
If x > 127; y = x - 256
Convert the signed counts (y) to RSSI in dBm, subtract -45 dBm
RSSI = y – 45 dBm
Example:
Raw Counts = 217
Convert to signed integer : 217 – 256 = -39
Calculate RSSI (dBm) : -39 – 45 = -84 dBm
2009년 7월 27일 월요일
MSP430F1611 Clock
MSP430 클럭은 ACLK, MCLK, SMCLK로 구분된다.
ACLK는 외부클럭을(32.768KHz) 사용하고 있다.
MCLK, SMCLK는 내부 DCO를 사용하고 있으며 기본 4MHz 동작하며
최대 8MHz까지 설정이 가능하다.
TinyOS를 사용하는 경우 클럭 설정은
/opt/tinyos-1.x/tos/platform/msp430/MSP430ClockM.nc
에서 확인 및 설정할 수 있다.
ACLK는 외부클럭을(32.768KHz) 사용하고 있다.
MCLK, SMCLK는 내부 DCO를 사용하고 있으며 기본 4MHz 동작하며
최대 8MHz까지 설정이 가능하다.
TinyOS를 사용하는 경우 클럭 설정은
/opt/tinyos-1.x/tos/platform/msp430/MSP430ClockM.nc
에서 확인 및 설정할 수 있다.
강의에 대한 10가지 이야기.
1. 처음부터 강의를 하지 않는다.
먼저 강의자와 청강자는 처음 보는 사람이다.(처음 보는 사람이 아니라도 그 강의를 시작하는데 있어서는 항상 처음이라 할 수 있다.) 무턱대고 강의를 시작하자면 둘다 준비된 상태가 아니기 때문에 강의의 내용이 바로 귀에서 머리로 전달되는데는 시간이 필요하다. 당신의 목소리가 청강자의 귀에 익숙해질 시간이 필요하다. 기기를 작동할때도 30분간 미리 작동을 시키고 실험을 할때도 예비가열을 하듯이 당신의 목소리에 익숙하질 시간이 필요하다. 간단한 자기소개로 우선 말을 꺼내고 (갑자기 봄이 와서 옷입기가 난감하다는지. 오는데 전철에서 이상한 변태를 보았다는지 등의 흔히 접하고 누구나 공감하지만 재미있는 화재) 언급한후 강의를 시작한다.
2.목차와 중요성 언급
강의를 하는데 어떠한 순서에 의해 이야기를 할것인지 이야기하고, 이 강의의 중요성에 대해 언급한다.
3. 산을 본후 나무를 보자.
내용은 전반적인 흐름을 먼저 이야기한 다음 세부사항으로 들어가도록 한다. 하나하나 세부사항을 먼저 언급하다보면 머리에 개념을 잡기 어려우니 포괄적인 면을 먼저 설명후 세부사항으로 들어가도록 한다. 세부사항을 설명할 때는 적절한 예를 제시하여 이해가 쉽게 되도록 한다.
4. 단락이 나누어지는 지점에서 확인 절차
1단계에서 2단계로 설명이 들어가기 전 지금까지 어떠한 부분에 대해 설명을 하였고, 여기서 잊어서는 안될 부분에 대해 한번씩 집고 넘어간다. 전체를 다 설명한 후에는 다시 한번 목차에 대해 언급을 하며, 오늘 강의 내용에 대해 청강자와 함께 정리하는 순서를 가진다. 설명한 내용에 대해 단락이 끝날때 요점을 정리하라 말했었는데, 청강자의 답변을 기다려서 강의에 참여할 수 있게 한다.
5. 질문을 받는다.
당신의 능력을 보여줄 차례이다. 그런데 혹시 난감한 질문이 들어온다면 아주 좋은 질문이라고 말한후 대략적 설명만 한 후 내용이 너무 길고 할당된 시간으로 인해 메일로 보내주시면 답변을 드리겠다는 식으로 위기를 모면해라.
6. 시간을 잘쪼개자.
명강의자의 경우에는 단락별 시간을 딱딱 나누어 설명한다. 그러나 흐름이 깨지지 않도록 하기 위해 세심한 부분도 유념하기도 한다.
7. 말로 전부 강의를 하려고 하지마라.
시각적 효과도 필요하다. 빈공간을 채우기도 힘들고 빈공간에 다 채우자면 너무 지루하고 괴롭다. 공감각적이면 더욱 좋겠다. 만질 수 있고 볼 수 있는것 말이다. 시각적인 표현은 슬라이드나, OHP를 사용하는데 OHP를 사용할 경우 너무 문자가 많고 디테일하기보다 계략적인 부분만 보여주고 나머지는 말로 설명한다. 결론적으로 말하자면 OHP는 키워드 중심으로 만든다. 공감각적 표현은 설명하는 내용에 관련된 제품을 보여주고 돌아가면서 자세히 볼 수 있도록 하는 방법 인데 자칫 잘못하면 강의가 어수선해질수 있으니 조심해야한다.
8. 강의자의 목소리 톤도 중요하다.
솔음이 가장 좋다고 하지만 그렇다고 억지로 올려서 서비스 직원이 된듯하게 될 경우라면 그냥 원래대로 해라. 하지만 목소리는 커야 한다. 부가적으로 의상과 인상도 추가된다.
9. 멘트를 작성한 다음 혼자 강의를 해봐라.
멘트만 보고 강의하는 자는 정말 매력없다. 강의의 흐름과 지식은 이미 알고 있는 상태이니청강자와 눈을 마주치며 강의 하도록 하자. 어떤 사람은 혼자 빈강의실에서 강의를 했다는 사람도 있다. 글로 작성한 것과 말로 표현하는 것은 조금 다르다. 작성후 혼자 꼭 !!! 강의해봐라.
10. 예시
안녕하세요. 저는 오늘 어려분에게 알파벳에 대해 강의를 하게된 파직스입니다. 오늘 날씨 너무 좋죠? 이런 날 벗꽃 구경이라도 가야 하는데 여러분들도 마음이 싱숭생숭하시겠지만 놀러가지 못하고 강의 준비하느라 노력한 착하고 불쌍한 저를 위해 경청해 주실거라 믿고 강의 시작하겠습니다. (이보다 길게 맨트를 준비한다. 약 5~10분정도로 이 작업이 목풀기 작업)아까 말씀 드렸던 바와 같이 오늘 저는 알파벳이라는 것에 대해 강의를 하겠습니다. 알파벳은 영어를 하려는 최소의 단위로 영어의 구성원이라 할수 있겠지요. 조금 말이 어렵지요? 예를 들어 ...
먼저 강의자와 청강자는 처음 보는 사람이다.(처음 보는 사람이 아니라도 그 강의를 시작하는데 있어서는 항상 처음이라 할 수 있다.) 무턱대고 강의를 시작하자면 둘다 준비된 상태가 아니기 때문에 강의의 내용이 바로 귀에서 머리로 전달되는데는 시간이 필요하다. 당신의 목소리가 청강자의 귀에 익숙해질 시간이 필요하다. 기기를 작동할때도 30분간 미리 작동을 시키고 실험을 할때도 예비가열을 하듯이 당신의 목소리에 익숙하질 시간이 필요하다. 간단한 자기소개로 우선 말을 꺼내고 (갑자기 봄이 와서 옷입기가 난감하다는지. 오는데 전철에서 이상한 변태를 보았다는지 등의 흔히 접하고 누구나 공감하지만 재미있는 화재) 언급한후 강의를 시작한다.
2.목차와 중요성 언급
강의를 하는데 어떠한 순서에 의해 이야기를 할것인지 이야기하고, 이 강의의 중요성에 대해 언급한다.
3. 산을 본후 나무를 보자.
내용은 전반적인 흐름을 먼저 이야기한 다음 세부사항으로 들어가도록 한다. 하나하나 세부사항을 먼저 언급하다보면 머리에 개념을 잡기 어려우니 포괄적인 면을 먼저 설명후 세부사항으로 들어가도록 한다. 세부사항을 설명할 때는 적절한 예를 제시하여 이해가 쉽게 되도록 한다.
4. 단락이 나누어지는 지점에서 확인 절차
1단계에서 2단계로 설명이 들어가기 전 지금까지 어떠한 부분에 대해 설명을 하였고, 여기서 잊어서는 안될 부분에 대해 한번씩 집고 넘어간다. 전체를 다 설명한 후에는 다시 한번 목차에 대해 언급을 하며, 오늘 강의 내용에 대해 청강자와 함께 정리하는 순서를 가진다. 설명한 내용에 대해 단락이 끝날때 요점을 정리하라 말했었는데, 청강자의 답변을 기다려서 강의에 참여할 수 있게 한다.
5. 질문을 받는다.
당신의 능력을 보여줄 차례이다. 그런데 혹시 난감한 질문이 들어온다면 아주 좋은 질문이라고 말한후 대략적 설명만 한 후 내용이 너무 길고 할당된 시간으로 인해 메일로 보내주시면 답변을 드리겠다는 식으로 위기를 모면해라.
6. 시간을 잘쪼개자.
명강의자의 경우에는 단락별 시간을 딱딱 나누어 설명한다. 그러나 흐름이 깨지지 않도록 하기 위해 세심한 부분도 유념하기도 한다.
7. 말로 전부 강의를 하려고 하지마라.
시각적 효과도 필요하다. 빈공간을 채우기도 힘들고 빈공간에 다 채우자면 너무 지루하고 괴롭다. 공감각적이면 더욱 좋겠다. 만질 수 있고 볼 수 있는것 말이다. 시각적인 표현은 슬라이드나, OHP를 사용하는데 OHP를 사용할 경우 너무 문자가 많고 디테일하기보다 계략적인 부분만 보여주고 나머지는 말로 설명한다. 결론적으로 말하자면 OHP는 키워드 중심으로 만든다. 공감각적 표현은 설명하는 내용에 관련된 제품을 보여주고 돌아가면서 자세히 볼 수 있도록 하는 방법 인데 자칫 잘못하면 강의가 어수선해질수 있으니 조심해야한다.
8. 강의자의 목소리 톤도 중요하다.
솔음이 가장 좋다고 하지만 그렇다고 억지로 올려서 서비스 직원이 된듯하게 될 경우라면 그냥 원래대로 해라. 하지만 목소리는 커야 한다. 부가적으로 의상과 인상도 추가된다.
9. 멘트를 작성한 다음 혼자 강의를 해봐라.
멘트만 보고 강의하는 자는 정말 매력없다. 강의의 흐름과 지식은 이미 알고 있는 상태이니청강자와 눈을 마주치며 강의 하도록 하자. 어떤 사람은 혼자 빈강의실에서 강의를 했다는 사람도 있다. 글로 작성한 것과 말로 표현하는 것은 조금 다르다. 작성후 혼자 꼭 !!! 강의해봐라.
10. 예시
안녕하세요. 저는 오늘 어려분에게 알파벳에 대해 강의를 하게된 파직스입니다. 오늘 날씨 너무 좋죠? 이런 날 벗꽃 구경이라도 가야 하는데 여러분들도 마음이 싱숭생숭하시겠지만 놀러가지 못하고 강의 준비하느라 노력한 착하고 불쌍한 저를 위해 경청해 주실거라 믿고 강의 시작하겠습니다. (이보다 길게 맨트를 준비한다. 약 5~10분정도로 이 작업이 목풀기 작업)아까 말씀 드렸던 바와 같이 오늘 저는 알파벳이라는 것에 대해 강의를 하겠습니다. 알파벳은 영어를 하려는 최소의 단위로 영어의 구성원이라 할수 있겠지요. 조금 말이 어렵지요? 예를 들어 ...
2009년 7월 22일 수요일
enum으로 선언한 변수의 값
enum은 상수 열거형 지시어다.
그 안에 상수정의가 특별한 값에 대입되어 있지 않다면 0부터 차례대로 자연수의 값을 갖는다.
또한, enum{}으로 선언한 변수는 컴파일러에서 16비트로 기억된다. 즉, int16_t로 선언된다.
enum {TIME = 61440}; 으로 하고 컴파일을 하게 되면 "warning: decimal constant is so large that it is unsigned" 라는 주의 메시지가 뜬다. 해당 값이 int16_t 에 담기에는 너무 크다고...
컴파일러는 똑똑해서 자기가 알아서 unsigned로 바꿔준다.
하지만 이게 보기 싫다면 해당 값의 끝에 "U"를 붙여 주면된다.
enum {TIME = 61440U};
이렇게 하면 unsigned라고 미리 알려주므로 warning은 뜨지 않는다. 보다 큰 숫자를 입력하고 싶다면 마찬가지로 해당 값의 끝에 "L"을 붙여 사용하도록 한다.
enum {TIME = 6144000L};
그 안에 상수정의가 특별한 값에 대입되어 있지 않다면 0부터 차례대로 자연수의 값을 갖는다.
또한, enum{}으로 선언한 변수는 컴파일러에서 16비트로 기억된다. 즉, int16_t로 선언된다.
enum {TIME = 61440}; 으로 하고 컴파일을 하게 되면 "warning: decimal constant is so large that it is unsigned" 라는 주의 메시지가 뜬다. 해당 값이 int16_t 에 담기에는 너무 크다고...
컴파일러는 똑똑해서 자기가 알아서 unsigned로 바꿔준다.
하지만 이게 보기 싫다면 해당 값의 끝에 "U"를 붙여 주면된다.
enum {TIME = 61440U};
이렇게 하면 unsigned라고 미리 알려주므로 warning은 뜨지 않는다. 보다 큰 숫자를 입력하고 싶다면 마찬가지로 해당 값의 끝에 "L"을 붙여 사용하도록 한다.
enum {TIME = 6144000L};
2009년 7월 18일 토요일
moteiv's boomerang
http://docs.tinyos.net/index.php/Boomerang
boomerang 2.0.1은 2006년 3월 처음 릴리즈되었으며, 현재 boomerang 2.0.4까지 다양한 버그를 수정하여 릴리즈되었다.
boomerang 의 핵심은 간단하게 구현된 저전력 메시 네트워크의 형태인 Delta 어플리케이션으로 소규모 네트워크에서 빠른 응답을 한다.
내부적으로 큐를 사용하여 이웃 노드의 테이블을 관리하고, 이웃 노드들의 LQI 및 재 전송과 같은 형태의 알고리즘(?)을 사용하여 네트워크의 신뢰성을 보장하고, 에너지 효율적인 동작을 하도록 구현되어있다.
boomerang 2.0.1은 2006년 3월 처음 릴리즈되었으며, 현재 boomerang 2.0.4까지 다양한 버그를 수정하여 릴리즈되었다.
boomerang 의 핵심은 간단하게 구현된 저전력 메시 네트워크의 형태인 Delta 어플리케이션으로 소규모 네트워크에서 빠른 응답을 한다.
내부적으로 큐를 사용하여 이웃 노드의 테이블을 관리하고, 이웃 노드들의 LQI 및 재 전송과 같은 형태의 알고리즘(?)을 사용하여 네트워크의 신뢰성을 보장하고, 에너지 효율적인 동작을 하도록 구현되어있다.
2009년 7월 13일 월요일
Output Power Configuration for the CC2420
▶ Output Power Configuration for the CC2420
Power Level Current Consumption(mA) Output Power(dBm)
0x1f(31) = 17.4mA = 0dBm
0x1b(27) = 16.5mA = -1dBm
0x17(23) = 15.2 mA = -3dBm
0x13(19) = 13.9mA = -5dBm
0x0f(15) = 12.5mA = -7dBm
0x0b(11) = 11.2mA = -10dBm
0x07(7) = 9.9mA = -15dBm
0x03(3) = 8.5mA = -25dBm
**거리가 멀수록 값이 작아지며, 가까울 수록 값이 커지지만 환경에 따라 크게 달라질 수 있다.
Power Level Current Consumption(mA) Output Power(dBm)
0x1f(31) = 17.4mA = 0dBm
0x1b(27) = 16.5mA = -1dBm
0x17(23) = 15.2 mA = -3dBm
0x13(19) = 13.9mA = -5dBm
0x0f(15) = 12.5mA = -7dBm
0x0b(11) = 11.2mA = -10dBm
0x07(7) = 9.9mA = -15dBm
0x03(3) = 8.5mA = -25dBm
**거리가 멀수록 값이 작아지며, 가까울 수록 값이 커지지만 환경에 따라 크게 달라질 수 있다.
센서 노드에 업로드 된 프로그램의 삭제
보통 센서 노드에 업로드 된 기존의 프로그램은 새로운 어플리케이션을 올림으로써 덮어쓰는 방식으로 사용한다. 이유는 귀찮기 때문이다. -.-
다음과 같은 방법을 사용해 보도록 하자.
--------------------------------------------------------------
센서 노드가 USB로 연결되었다는 가정하에
$>tos-bsl --telosb -c /dev/ttyUSB0 -r -e 명령으로 실행하면
MSP430 Bootstrap Loader Version: 1.39-telos-8
Use -h for help
Mass Erase...
Transmit default password...
Reset device...
--------------------------------------------------------------
끝.
다음과 같은 방법을 사용해 보도록 하자.
--------------------------------------------------------------
센서 노드가 USB로 연결되었다는 가정하에
$>tos-bsl --telosb -c /dev/ttyUSB0 -r -e 명령으로 실행하면
MSP430 Bootstrap Loader Version: 1.39-telos-8
Use -h for help
Mass Erase...
Transmit default password...
Reset device...
--------------------------------------------------------------
끝.
2009년 7월 12일 일요일
리눅스에서 특정 파일 삭제
swp 파일이나 tmp 파일이 남아있게 된 경우 다음과 같은 방법으로 날릴 수 있다.
ex) vim의 swp 파일 삭제
$>find . -name *.swp -exec rm -f {} \;
경로 설정시 주의...
ex) vim의 swp 파일 삭제
$>find . -name *.swp -exec rm -f {} \;
경로 설정시 주의...
2009년 7월 6일 월요일
use the Listen java program to record the output stream.
Listen command on Terminal:
$ export MOTECOM=serial@/dev/ttyUSB0:platform name
$ java net.tinyos.tools.Listen > TestOutput.txt or
$ java net.tinyos.tools.Listen | TestOutput.txt
$ export MOTECOM=serial@/dev/ttyUSB0:platform name
$ java net.tinyos.tools.Listen > TestOutput.txt or
$ java net.tinyos.tools.Listen | TestOutput.txt
2009년 6월 28일 일요일
Beginning on the stargate
I think there is a 2nd alternative to using java for sending andreceiving packets from the mote.
If you look at tinyos-1.x/tools/src/sf there are some C files that followthe serial framing protocol used by the motes to send TOS packets over theserial port.
I think this directory contains the implementation of theSerialForwarder is C.
I have only used the serialsource.c and seriallisten.c and compiled themtogether to produce a TinyOS packet dump of the serial port.
So do the following on your PC:
$ cd/tools/src/sf
$ gcc -o seriallisten serialsource.c seriallisten.c
$./seriallisten /dev/ttyUSB0 57600
is where you have installed tinyos (e.g /opt/tinyos-1.x).
If you look at tinyos-1.x/tools/src/sf there are some C files that followthe serial framing protocol used by the motes to send TOS packets over theserial port.
I think this directory contains the implementation of theSerialForwarder is C.
I have only used the serialsource.c and seriallisten.c and compiled themtogether to produce a TinyOS packet dump of the serial port.
So do the following on your PC:
$ cd
$ gcc -o seriallisten serialsource.c seriallisten.c
$./seriallisten /dev/ttyUSB0 57600
- xbow -
2009년 6월 18일 목요일
moteiv boomerang 환경설정
# tinyos_boomerang.sh : Prepare environment for Boomerang
# Place this file in /etc/profile.d/
export MOTEIV_DIR=/opt/tinyos-1.x/contrib/boomerang
export TOSMAKE_PATH=$MOTEIV_DIR/tools/make
# help build files in $TOSDIR/../tools/java/net/tinyos
export MIGFLAGS="-target=telosb -I$TOSDIR/lib/CC2420Radio"
export SURGE_PLATFORM=telos
for a in $MOTEIV_DIR/tools/java/jars/* $MOTEIV_DIR/tools/java
do
if [ -f /bin/cygwin1.dll ]; then
export CLASSPATH="`cygpath -w "$a"`;$CLASSPATH"
else
export CLASSPATH="$a:$CLASSPATH"
fi
done
# Place this file in /etc/profile.d/
export MOTEIV_DIR=/opt/tinyos-1.x/contrib/boomerang
export TOSMAKE_PATH=$MOTEIV_DIR/tools/make
# help build files in $TOSDIR/../tools/java/net/tinyos
export MIGFLAGS="-target=telosb -I$TOSDIR/lib/CC2420Radio"
export SURGE_PLATFORM=telos
for a in $MOTEIV_DIR/tools/java/jars/* $MOTEIV_DIR/tools/java
do
if [ -f /bin/cygwin1.dll ]; then
export CLASSPATH="`cygpath -w "$a"`;$CLASSPATH"
else
export CLASSPATH="$a:$CLASSPATH"
fi
done
2009년 6월 17일 수요일
windows에 T1 & T2 설치.
windows에 t1과 t2를 설치, cygwin을 이용한 개발 환경을 구축하기 위해서는
1. Java SDK 설치
java 1.5 jdk -> http://java.sun.com/
2. cygwin 설치
http://www.cygwin.com/ or
http://www.tinyos.net/dist-1.2.0/tools/windows/cygwin-1.2a.tgz
setup - Install from Local Directory - Root Directory 설정 - Select Package All install로 모두 설정 - install
3. cygwin-x 설치
http://www.cygwin.com/setup.exe
setup - install from internet - directory 설정 - 다운로드 받을 임시 디렉토리 설정 - Use IE5 Settings - FTP site 설정 - X11 항목 install - install
설치 완료 후 startxwin.sh 를 실행하여 설치 확인
4. TI MSP430 Tools 설치
http://www.tinyos.net/dist-1.2.0/tools/windows/
설치 명령 : rpm -ivh --ignoreos --nodeps --force
-base-0.1
-python-tools-1.0-1
-binutils-2.16
-gcc-3.2.3
-libc
5. TinyOS Toolchain (nesC, tinyos-tools) 설치
http://www.tinyos.net/dist-1.2.0/tinyos/windows/
-nesc-1.2.8a-1
-tinyos-tools-1.2.3-1
6. Graphviz 설치
http://www.graphviz.org/
7. tinyos 1.x & 2.x & 2.x-contrib source tree 다운로드
$ cd /opt
$ cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos login
$ cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co -P tinyos-1.x tinyos-2.x tinyos-2.x-contrib
8. 환경설정
$ vim ~/.bashrc
export TOSROOT=/opt/tinyos-2.x
export TOSDIR = $TOSROOT/tos
export CLASSPATH = `cygpath -w $TOSROOT/support/sdk/java/tinyos.jar`
export CLASSPATH = "$CLASSPATH;."
export MAKERULES = $TOSROOT/support/make/Makerules
export PATH = /opt/msp430/bin:$PATH
$ source ~/.bashrc
9. java tool 컴파일
$ tos-install-jni
10. 설치 후 검증
$ cd /opt/tinyos-1.x/tools/script
$ ./toscheck
1. Java SDK 설치
java 1.5 jdk -> http://java.sun.com/
2. cygwin 설치
http://www.cygwin.com/ or
http://www.tinyos.net/dist-1.2.0/tools/windows/cygwin-1.2a.tgz
setup - Install from Local Directory - Root Directory 설정 - Select Package All install로 모두 설정 - install
3. cygwin-x 설치
http://www.cygwin.com/setup.exe
setup - install from internet - directory 설정 - 다운로드 받을 임시 디렉토리 설정 - Use IE5 Settings - FTP site 설정 - X11 항목 install - install
설치 완료 후 startxwin.sh 를 실행하여 설치 확인
4. TI MSP430 Tools 설치
http://www.tinyos.net/dist-1.2.0/tools/windows/
설치 명령 : rpm -ivh --ignoreos --nodeps --force
-base-0.1
-python-tools-1.0-1
-binutils-2.16
-gcc-3.2.3
-libc
5. TinyOS Toolchain (nesC, tinyos-tools) 설치
http://www.tinyos.net/dist-1.2.0/tinyos/windows/
-nesc-1.2.8a-1
-tinyos-tools-1.2.3-1
6. Graphviz 설치
http://www.graphviz.org/
7. tinyos 1.x & 2.x & 2.x-contrib source tree 다운로드
$ cd /opt
$ cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos login
$ cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co -P tinyos-1.x tinyos-2.x tinyos-2.x-contrib
8. 환경설정
$ vim ~/.bashrc
export TOSROOT=/opt/tinyos-2.x
export TOSDIR = $TOSROOT/tos
export CLASSPATH = `cygpath -w $TOSROOT/support/sdk/java/tinyos.jar`
export CLASSPATH = "$CLASSPATH;."
export MAKERULES = $TOSROOT/support/make/Makerules
export PATH = /opt/msp430/bin:$PATH
$ source ~/.bashrc
9. java tool 컴파일
$ tos-install-jni
10. 설치 후 검증
$ cd /opt/tinyos-1.x/tools/script
$ ./toscheck
2009년 6월 2일 화요일
컴파일 및 빌드 시 target name 변경
* opt/tinyos-1.x/tools/make 폴더 내에 target name.target 파일 생성.
-> telosb 계열의 경우 telosb.target의 내용을 복사해서 사용한다.
변경할 내용은 다음과 같다.
-------------------------------------------
...
PLATFORM ?= target name
...
$(call TOSMake_include_platform, msp)
target name : $(BUILD_DEPS)
...
-------------------------------------------
* opt/tinyos-1.x/tos/platform 폴더 내에 해당 target device 폴더 생성.
-> telosb 계열의 플랫폼일 경우 telosb 폴더를 복사해서 사용한다.
상위 target name 과 같은 플랫폼 이름을 적용해야 한다.
-> telosb 계열의 경우 telosb.target의 내용을 복사해서 사용한다.
변경할 내용은 다음과 같다.
-------------------------------------------
...
PLATFORM ?= target name
...
$(call TOSMake_include_platform, msp)
...
-------------------------------------------
* opt/tinyos-1.x/tos/platform 폴더 내에 해당 target device 폴더 생성.
-> telosb 계열의 플랫폼일 경우 telosb 폴더를 복사해서 사용한다.
상위 target name 과 같은 플랫폼 이름을 적용해야 한다.
2009년 5월 23일 토요일
OTA(Over The Air)
Deluge는 대규모 센서 네트워크에서 센서 노드들의 무선 프로그래밍을 가능하게 한다. 컴파일 된 프로그램의 binary와 같은 data object를 네트워크내에 있는 센서 노드들에게 퍼뜨리는 방법으로 이를 보통 OTA(Over the Air) Programming or Reprogramming 이라고 한다. 센서 네트워크에서 네트워크를 이루고 있는 센서 노드의 갯수가 증가할 경우에, 센서 노드에 일일이 프로그램을 다운로드하는 것은 비효율적이다. 이 경우 Deluge 매카니즘을 사용하게 되면 매우 효과적이다.
Deluge 2.0
- Goals :
• robustness & useability가 강화된 network programming
- Features :
• Multihop 지원 : multihop 네트워크 안의 모든 노드에 무선으로 프로그램 적재
• Epidemic propagation : 모든 노드에 의한 연속적인 전파 전달로, 통신율이 낮은 노드에도 전파 전달이 되도록 기여함.
• Redundant data integrity checks : CRC계산으로, 모든 노드의 프로그램 이미지 무결성을 보장하도록 기여함.
• Store multiple program images : 프로그램 이미지를 여러 개 저장함으로써, 계속되는 다운로드 없이도, 프로그램을 빠르게 교환.
• Golden image : 최소한의 network programming을 지원하는 프로그램 이미지로 외부 flash의 안전한 위치에 저장된다. 복구에 필요한 코드 부분이 있다.
• Isolated bootloader : TinyOS 어플리케이션의 리셋 후에 실행을 보장하는 코드. bootloader는 마이크로컨트롤러 프로그래밍과 관련되어 있으며, 프로그래밍 에러시 Golden Image를 읽어서 복구한다.
• Rollback gesture : 노드 고장시, 리셋 스위치를 여러 번 누르면, Golden image로 전환되어 새로운 프로그램을 받아들일 수 있도록 준비됨.
• Small RAM foot print : 150byte 미만의 메모리 차지.
- Improvement :
• 프로그래밍 전에 이미지가 유효한가에 대한 이미지 검증
• 프로그래밍 실패시 자동으로 Golden Image로 rollbak
• 어플리케이션의 의한 Golden image의 수정을 방지
• 프로그램에 대한 다양한 정보(program name, compile time, host name ...)
• CRC를 포함한 metadata 데이터구조를 사용
• Deluge나 TOSBase node 연결시 자동으로 감지
• 불완전한 이미지 자동 재시작
• 동일한 이미지 자동 감지
- Compatible platform :
• Mica2, Mica2-doc, MicaZ, Telos Rev.A, Telos Rev.B, TmoteSky
- Deluge Testing :
•
• Formatting the Flash ; Flash 메모리의 FAT를 위한 formatting
1) tinyos-1.x/apps/TestDeluge의 FlashFormat 어플리케이션 install
2) reset후 자동으로 포맷 시작(Yellow On), Success종료(Green On), Fail종료(Red On)
• Installing Deluge ; 기본 Deluge 어플리케이션과 TOSBoot 인스톨
1) tinyos-1.x/apps/TestDeluge의 DelugeBasic 어플리케이션 install(must set node ID)
• Pinging the Node ; Deluge java tool chain으로 현재 노드의 Deluge확인
1) Deluge가 적용된 노드를 UART로 연결한다.(SerialForwarder 혹은 MOTECOM 환경변수 설정)
2) java net.tinyos.tools.Deluge --ping
3) result screen
• Installing the Golden Image ; Deluge를 지원하는 최소 기능을 포함한 TinyOS application
1) application compile
2) build/telosb/tos_image.xml 생성 확인
3) java net.tinyos.tools.Deluge -i -in=0 -ti=./build/telosb/tos_image.xml 명령으로 Golden Image 생성 및 업로드(Golden image는 특별한 어플리케이션으로 직접연결로만 다운로드 가능)
4) 다른 노드에도 1~3의 과정으로 Golden image 다운로드 할 것.
• preparing your code : deluge 사용을 위해 사용자 어플리케이션에 deluge적용
1) top level configuration에서 DelugeC Component 추가, Main과 DelugeC wiring
• injecting a New Program image
1) java net.tinyos.tools.Deluge -i -in=1 -ti=./build/telosb/tos_image.xml
• reprogramming with a New program image
1) java net.tinyos.tools.Deluge -r -in=1(1번 image가 프로그래밍되어 동작됨. (GroupID, NodeID 유지됨))
- Deluge command :
• Ping
# java net.tinyos.tools.Deluge --ping
• Inject
# java net.tinyos.tools.Deluge --inject --tos_image= --imgnum=
• Reboot
# java net.tinyos.tools.Deluge --reboot --imgnum=
• Erase
# java net.tinyos.tools.Deluge --erase --imgnum=
• Reset
# java net.tinyos.tools.Deluge --reset --imgnum=
• Dump(extract)
# java net.tinyos.tools.Deluge --dump --imgnum= --outfile=
Deluge 2.0
- Goals :
• robustness & useability가 강화된 network programming
- Features :
• Multihop 지원 : multihop 네트워크 안의 모든 노드에 무선으로 프로그램 적재
• Epidemic propagation : 모든 노드에 의한 연속적인 전파 전달로, 통신율이 낮은 노드에도 전파 전달이 되도록 기여함.
• Redundant data integrity checks : CRC계산으로, 모든 노드의 프로그램 이미지 무결성을 보장하도록 기여함.
• Store multiple program images : 프로그램 이미지를 여러 개 저장함으로써, 계속되는 다운로드 없이도, 프로그램을 빠르게 교환.
• Golden image : 최소한의 network programming을 지원하는 프로그램 이미지로 외부 flash의 안전한 위치에 저장된다. 복구에 필요한 코드 부분이 있다.
• Isolated bootloader : TinyOS 어플리케이션의 리셋 후에 실행을 보장하는 코드. bootloader는 마이크로컨트롤러 프로그래밍과 관련되어 있으며, 프로그래밍 에러시 Golden Image를 읽어서 복구한다.
• Rollback gesture : 노드 고장시, 리셋 스위치를 여러 번 누르면, Golden image로 전환되어 새로운 프로그램을 받아들일 수 있도록 준비됨.
• Small RAM foot print : 150byte 미만의 메모리 차지.
- Improvement :
• 프로그래밍 전에 이미지가 유효한가에 대한 이미지 검증
• 프로그래밍 실패시 자동으로 Golden Image로 rollbak
• 어플리케이션의 의한 Golden image의 수정을 방지
• 프로그램에 대한 다양한 정보(program name, compile time, host name ...)
• CRC를 포함한 metadata 데이터구조를 사용
• Deluge나 TOSBase node 연결시 자동으로 감지
• 불완전한 이미지 자동 재시작
• 동일한 이미지 자동 감지
- Compatible platform :
• Mica2, Mica2-doc, MicaZ, Telos Rev.A, Telos Rev.B, TmoteSky
- Deluge Testing :
•
• Formatting the Flash ; Flash 메모리의 FAT를 위한 formatting
1) tinyos-1.x/apps/TestDeluge의 FlashFormat 어플리케이션 install
2) reset후 자동으로 포맷 시작(Yellow On), Success종료(Green On), Fail종료(Red On)
• Installing Deluge ; 기본 Deluge 어플리케이션과 TOSBoot 인스톨
1) tinyos-1.x/apps/TestDeluge의 DelugeBasic 어플리케이션 install(must set node ID)
• Pinging the Node ; Deluge java tool chain으로 현재 노드의 Deluge확인
1) Deluge가 적용된 노드를 UART로 연결한다.(SerialForwarder 혹은 MOTECOM 환경변수 설정)
2) java net.tinyos.tools.Deluge --ping
3) result screen
• Installing the Golden Image ; Deluge를 지원하는 최소 기능을 포함한 TinyOS application
1) application compile
2) build/telosb/tos_image.xml 생성 확인
3) java net.tinyos.tools.Deluge -i -in=0 -ti=./build/telosb/tos_image.xml 명령으로 Golden Image 생성 및 업로드(Golden image는 특별한 어플리케이션으로 직접연결로만 다운로드 가능)
4) 다른 노드에도 1~3의 과정으로 Golden image 다운로드 할 것.
• preparing your code : deluge 사용을 위해 사용자 어플리케이션에 deluge적용
1) top level configuration에서 DelugeC Component 추가, Main과 DelugeC wiring
• injecting a New Program image
1) java net.tinyos.tools.Deluge -i -in=1 -ti=./build/telosb/tos_image.xml
• reprogramming with a New program image
1) java net.tinyos.tools.Deluge -r -in=1(1번 image가 프로그래밍되어 동작됨. (GroupID, NodeID 유지됨))
- Deluge command :
• Ping
# java net.tinyos.tools.Deluge --ping
• Inject
# java net.tinyos.tools.Deluge --inject --tos_image=
• Reboot
# java net.tinyos.tools.Deluge --reboot --imgnum=
• Erase
# java net.tinyos.tools.Deluge --erase --imgnum=
• Reset
# java net.tinyos.tools.Deluge --reset --imgnum=
• Dump(extract)
# java net.tinyos.tools.Deluge --dump --imgnum=
2009년 5월 20일 수요일
T1에서 컴파일 에러 문제
xubuntu 플랫폼에서 t1의 경우 nesc 컴파일러 1.3.0 버전을 사용하면 컴파일시 에러가 발생하는 경우가 생긴다. (대표적으로 DemoSensorC 컴포넌트 및 하위 인터페이스)
** version 확인은 다음과 같이...
#nescc --version
이를 해결하기 위해서는 nesc 컴파일러를 1.2.8a를 새로 설치하면 된다.
설치방법은 http://www.tinyos.net/dist-2.0.0/tinyos/linux 에서 해당 컴파일러를 찾아 다운로드 한 후, rpm 파일을 deb 파일로 변환하여 설치하도록 한다.
** version 확인은 다음과 같이...
#nescc --version
이를 해결하기 위해서는 nesc 컴파일러를 1.2.8a를 새로 설치하면 된다.
설치방법은 http://www.tinyos.net/dist-2.0.0/tinyos/linux 에서 해당 컴파일러를 찾아 다운로드 한 후, rpm 파일을 deb 파일로 변환하여 설치하도록 한다.
windows에 t1 설치 및 삭제
* windows에 tinyos-1.x 설치하기.
1. http://www.tinyos.net/dist-1.1.0/tinyos/windows/ 에서 tinyos-1.1.0-1is.exe를 다운로드 받아 실행한다.
2. t1의 최신버전인 1.1.15로 업그레이드 하기 위해 마찬가지로 위 사이트에서 tinyos-1.1.15Dec2005cvs-1.cygwin.noarch.rpm을 cygwin이 설치된 하부 디렉토리내에 다운로드 한다.
3. cygwin을 실행하여 1.1.15 rpm 파일이 위치한 곳으로 이동하여 다음 명령을 통해 업그레이드 하면 끝.
$ rpm --force --ignoreos -Uvh tinyos-1.1.15Dec2005cvs-1.cygwin.noarch.rpm
4. 설치가 완료되면 rpm -qa 명령을 통해 설치된 내용을 확인한다.
** windows에서 tinyos-1.x 삭제하기.
설치된 tinyos를 삭제하기 위해서는 다음의 순서를 꼭 따라야한다. 아니면 이 후 재설치 시 설치가 되지 않는 문제가 생길 수 있다.
1. 바탕화면의 Cygwin 바로가기 삭제
2. 시작-프로그램-Cygwin 폴더 삭제
3. 제어판-프로그램 추가/삭제-TinyOS 삭제
4. C:\Program Files\UCB 삭제
5. 시작-실행-regedit 를 실행한 후 Software\Cygnus Solutions 를 찾아 모두 삭제
1. http://www.tinyos.net/dist-1.1.0/tinyos/windows/ 에서 tinyos-1.1.0-1is.exe를 다운로드 받아 실행한다.
2. t1의 최신버전인 1.1.15로 업그레이드 하기 위해 마찬가지로 위 사이트에서 tinyos-1.1.15Dec2005cvs-1.cygwin.noarch.rpm을 cygwin이 설치된 하부 디렉토리내에 다운로드 한다.
3. cygwin을 실행하여 1.1.15 rpm 파일이 위치한 곳으로 이동하여 다음 명령을 통해 업그레이드 하면 끝.
$ rpm --force --ignoreos -Uvh tinyos-1.1.15Dec2005cvs-1.cygwin.noarch.rpm
4. 설치가 완료되면 rpm -qa 명령을 통해 설치된 내용을 확인한다.
** windows에서 tinyos-1.x 삭제하기.
설치된 tinyos를 삭제하기 위해서는 다음의 순서를 꼭 따라야한다. 아니면 이 후 재설치 시 설치가 되지 않는 문제가 생길 수 있다.
1. 바탕화면의 Cygwin 바로가기 삭제
2. 시작-프로그램-Cygwin 폴더 삭제
3. 제어판-프로그램 추가/삭제-TinyOS 삭제
4. C:\Program Files\UCB 삭제
5. 시작-실행-regedit 를 실행한 후 Software\Cygnus Solutions 를 찾아 모두 삭제
2009년 5월 17일 일요일
duty cycle
듀티 사이클 (duty cycle)
송신 신호가 개폐되면서 한 주기를 이룰 때, 한 주기(= 전류가 흐른 시간 + 전류가 흐르지 않은 시간)에 대한 전류가 흐른 시간의 비를 듀티 사이클이라 하며, 또 전류가 흐르지 않은 시간에 대한 전류가 흐른 시간의 비를 듀티 비라고 한다.
송신 신호가 개폐되면서 한 주기를 이룰 때, 한 주기(= 전류가 흐른 시간 + 전류가 흐르지 않은 시간)에 대한 전류가 흐른 시간의 비를 듀티 사이클이라 하며, 또 전류가 흐르지 않은 시간에 대한 전류가 흐른 시간의 비를 듀티 비라고 한다.
2009년 5월 15일 금요일
TinyOS-2.x Overview
1. Introduction
TinyOS 2.0 is a clean slate redesign and re-implementation of TinyOS. Its development was motivated by our belief that many aspects of 1.x strain to meet requirements and uses that were not foreseen when it was designed and implemented. The structure and interfaces 1.x defines have several fundamental limitations. While these limitations can be worked around, this practice has led to tightly coupled components, hard to find interactions, and a very steep learning curve for a newcomer to sensor network programming.
TinyOS 2.0 is not backwards compatible with 1.x: code written for the latter will not compile for the former. However, one important aspect of 2.0's design is to minimize the difficulty of upgrading code. Therefore, while porting a 1.x application to 2.0 will require some work, it should not be very much.
This document provides a high-level overview of 2.0 and describes some of the ways in which it departs from 1.x. It covers the basic TinyOS abstractions, such as hardware abstractions, communication, timers, the scheduler, booting and initialization. Further detail on each of these can be found in TEPs (TinyOS Enhancement Proposals), which document and describe these abstractions.
2. Platforms/Hardware Abstraction
Platforms exist in the tos/platforms subdirectory. In TinyOS 2.0, a platform is a collection of chips and some glue code that connects them together. For example, the mica2 platform is the CC1000 radio chip and the ATmega128 microcontroller, while the micaZ platform is the CC2420 radio and the ATmega128 microcontroller, and the Teloi platforms are the CC2420 radio and the MSP430 microcontroller. Chip code exists in tos/chips. A platform directory generally has a .platform file, which has options to pass to the nesC compiler. For example, the mica2 .platform file tells ncc to look in chips/cc1000 and chips/atm128 directories, as well as to use avr-gcc to compile a mote binary (Teloi platforms tell it to use msp430-gcc).
Hardware abstractions in TinyOS 2.0 generally follow a three-level abstaction heirarchy, called the HAA (Hardware Abstraction Architecture).
At the bottom of the HAA is the HPL (Hardware Presentation Layer). The HPL is a thin software layer on top of the raw hardware, presenting hardare such as IO pins or registers as nesC interfaces. The HPL generally has no state besides the hardware itself (it has no variables). HPL components usually have the prefix Hpl, followed by the name of the chip. For example, the HPL components of the CC1000 begin with HplCC1000.
The middle of the HAA is the HAL (Hardware Abstraction Layer). The HAL builds on top of the HPL and provides higher-level abstractions that are easier to use than the HPL but still provide the full functionality of the underlying hardware. The HAL components usually have a prefix of the chip name. For example, the HAL components of the CC1000 begin with CC1000.
The top of the HAA is the HIL (Hardware Independent Layer). The HIL builds on top of the HAL and provides abstractions that are hardware independent. This generalization means that the HIL usually does not provide all of the functionality that the HAL can. HIL components have no naming prefix, as they represent abstractions that applications can use and safely compile on multiple platforms. For example, the HIL component of the CC1000 on the mica2 is ActiveMessageC, representing a full active message communication layer.
The HAA is described in TEP 2: Hardware Abstraction Architecture[TEP2].
Currently (as of the 2.0 release in November 2006), TinyOS 2.0 supports the following platforms:
•eyesIFXv2
•intelmote2
•mica2
•mica2dot
•micaZ
•telosb
•tinynode
•btnode3
The btnode3 platform is not included in the RPM.
3. Scheduler
As with TinyOS 1.x, TinyOS 2.0 scheduler has a non-preemptive FIFO policy. However, tasks in 2.0 operate slightly differently than in 1.x.
In TinyOS 1.x, there is a shared task queue for all tasks, and a component can post a task multiple times. If the task queue is full, the post operation fails. Experience with networking stacks showed this to be problematic, as the task might signal completion of a split-phase operation: if the post fails, the component above might block forever, waiting for the completion event.
In TinyOS 2.x, every task has its own reserved slot in the task queue, and a task can only be posted once. A post fails if and only if the task has already been posted. If a component needs to post a task multiple times, it can set an internal state variable so that when the task executes, it reposts itself.
This slight change in semantics greatly simplifies a lot of component code. Rather than test to see if a task is posted already before posting it, a component can just post the task. Components do not have to try to recover from failed posts and retry. The cost is one byte of state per task. Even in large systems such as TinyDB, this cost is under one hundred bytes (in TinyDB is is approximately 50).
Applications can also replace the scheduler, if they wish. This allows programmers to try new scheduling policies, such as priority- or deadline-based. It is important to maintain non-preemptiveness, however, or the scheduler will break all nesC's static concurrency analysis. Details on the new scheduler and how to extend it can be found in TEP 106: Schedulers and Tasks[TEP106].
4. Booting/Initialization
TinyOS 2.0 has a different boot sequence than 1.x. The 1.x interface StdControl has been split into two interfaces: Init and StdControl. The latter only has two commands: start and stop. In TinyOS 1.x, wiring components to the boot sequence would cause them to be powered up and started at boot. That is no longer the case: the boot sequence only initializes components. When it has completed initializing the scheduler, hardware, and software, the boot sequence signals the Boot.booted event. The top-level application component handles this event and start services accordingly. Details on the new boot sequence can be found in TEP 107: TinyOS 2.x Boot Sequence[TEP107].
5. Virtualization
TinyOS 2.0 is written with nesC 1.2, which introduces the concept of a 'generic' or instantiable component. Generic modules allow TinyOS to have reusable data structures, such as bit vectors and queues, which simplify development. More importantly, generic configurations allow services to encapsulate complex wiring relationships for clients that need them.
In practice, this means that many basic TinyOS services are now virtualized. Rather than wire to a component with a parameterized interface (e.g., GenericComm or TimerC in 1.x), a program instantiates a service component that provides the needed interface. This service component does all of the wiring underneath (e.g., in the case of timers, to a unique) automatically, reducing wiring mistakes and simplifying use of the abstraction.
6. Timers
TinyOS 2.0 provides a much richer set of timer interfaces than 1.x. Experience has shown that timers are one of the most critical abstractions a mote OS can provide, and so 2.0 expands the fidelity and form that timers take. Depending on the hardware resources of a platform, a component can use 32KHz as well as millisecond granularity timers, and the timer system may provide one or two high-precision timers that fire asynchronously (they have the async keyword). Components can query their timers for how much time remainins before they fire, and can start timers in the future (e.g., 'start firing a timer at 1Hz starting 31ms from now'). TEP 102: Timers[TEP102] defines what HIL components a platform must provide in order to support standard TinyOS timers. Platforms are required to provide millisecond granularity timers, and can provide finer granularity timers (e.g., 32kHz) if needed.
Timers present a good example of virtualization in 2.0. In 1.x, a program instantiates a timer by wiring to TimerC:
components App, TimerC;
App.Timer -> TimerC.Timer[unique("Timer")];
In 2.0, a program instantiates a timer:
components App, new TimerMilliC();
App.Timer -> TimerMilliC;
7. Communication
In TinyOS 2.0, the message buffer type is message_t, and it is a buffer that is large enough to hold a packet from any of a node's communication interfaces. The structure itself is completely opaque: components cannot reference its fields. Instead, all buffer accesses go through interfaces. For example, to get the destination address of an AM packet named msg, a component calls AMPacket.destination(msg).
Send interfaces distinguish the addressing mode of communication abstractions. For example, active message communication has the AMSend interface, as sending a packet require an AM destination address. In contrast, broadcasting and collection tree abstractions have the address-free Send interface.
Active messages are the network HIL. A platform's ActiveMessageC component defines which network interface is the standard communication medium. For example, a mica2 defines the CC1000 active message layer as ActiveMessageC, while the TMote defines the CC2420 active message layer as ActiveMessageC.
There is no longer a TOS_UART_ADDRESS for active message communication. Instead, a component should wire to SerialActiveMessageC, which provides active message communication over the serial port.
Active message communication is virtualized through four generic components, which take the AM type as a parameter: AMSenderC, AMReceiverC, AMSnooperC, and AMSnoopingReceiverC. AMSenderC is virtualized in that the call to send() does not fail if some other component is sending (as it does with GenericComm in 1.x). Instead, it fails only if that particular AMSenderC already has a packet outstanding or if the radio is not in a sending state. Underneath, the active message system queues and sends these outstanding packets. This is different than the QueuedSendC approach of 1.x, in which there is an N-deep queue that is shared among all senders. With N AMSenderC components, there is an N-deep queue where each sender has a single reserved entry. This means that each AMSenderC receives 1/n of the available post-MAC transmission opportunities, where n is the number of AMSenderC components with outstanding packets. In the worst case, n is the number of components; even when every protocol and component that sends packets is trying to send a packet, each one will receive its fair share of transmission opportunities.
Further information on message_t can be found in TEP 111: message_t[TEP111], while further information on AM can be found in TEP 116: Packet Protocols[TEP116].
The current TinyOS release has a low-power stack for the CC1000 radio (mica2 platform) and an experimental low-power stack for the CC2420 radio (micaz, telosb, and intelmote2 platforms).
8. Sensors
In TinyOS 2.0, named sensor components comprise the HIL of a platform's sensors. TEP 114 describes a set of HIL data acquisition interfaces, such as Read, ReadStream, and Get, which sensors provide according to their acquisition capabilities.
If a component needs high-frequency or very accurate sampling, it must use the HAL, which gives it the full power of the underlying platform (highly accurate platform-independent sampling is not really feasible, due to the particulars of individual platforms). Read assumes that the request can tolerate some latencies (for example, it might schedule competing requests using a FIFO policy).
Details on the ADC subsystem can be found in TEP 101: Analog-to-Digital Converters[TEP101]; details on the organization of sensor boards can be found in TEP 109: Sensorboards[TEP109], and the details of the HIL sensor interfaces can be found in TEP 114: Source and Sink Independent Drivers[TEP114].
9. Error Codes
The standard TinyOS 1.x return code is result_t, whose value is either SUCCESS (a non-zero value) or FAIL (a zero value). While this makes conditionals on calls very easy to write (e.g., if (call A.b())), it does not allow the callee to distinguish causes of error to the caller. In TinyOS 2.0, result_t is replaced by error_t, whose values include SUCCESS, FAIL, EBUSY, and ECANCEL. Interface commands and events define which error codes they may return and why.
From the perspective of porting code, this is the most significant different in 2.0. Calls that were once:
if (call X.y()) {
busy = TRUE;
}
now have their meanings reversed. In 1.x, the busy statement will execute if the call succeeds, while in 2.0 it will execute if the call fails. This encourages a more portable, upgradable, and readable approach:
if (call X.y() == SUCCESS) {
busy = TRUE;
}
10. Arbitration
While basic abstractions, such as packet communication and timers, can be virtualized, experiences with 1.x showed that some cannot without either adding significant complexity or limiting the system. The most pressing example of this is a shared bus on a microcontroller. Many different systems -- sensors, storage, the radio -- might need to use the bus at the same time, so some way of arbitrating access is needed.
To support these kinds of abstractions, TinyOS 2.0 introduces the Resource interface, which components use to request and acquire shared resources, and arbiters, which provide a policy for arbitrating access between multiple clients. For some abstractions, the arbiter also provides a power management policy, as it can tell when the system is no longer needed and can be safely turned off.
TEP 108: Resource Arbitration[TEP108] describes the Resource interface and how arbiters work.
11. Power Management
Power management in 2.0 is divided into two parts: the power state of the microcontroller and the power state of devices. The former, discussed in TEP 112: Microcontroller Power Management[TEP112], is computed in a chip-specific manner by examining which devices and interrupt souces are active. The latter, discussed in TEP 115: Power Management of Non-Virtualised Devices{TEP115], is handled through resource abiters. Fully virtualized services have their own, individual power management policies.
TinyOS 2.0 provides low-power stacks for the CC1000 (mica2) and CC2420 (micaz, telosb, imote2) radios. Both use a low-power listening apporach, where transmitters send long preambles or repeatedly send packets and receivers wake up periodically to sense the channel to hear if there is a packet being transmitted. The low-power stack CC1000 is standard, while the CC2420 stack is experimental. That is, the default CC1000 stack (chips/cc1000) has low-power-listening, while the default CC2420 stack (chips/cc2420) does not. To use the low-power CC2420 stack, you must include chips/cc2420_lpl in your application Makefile.
12. Network Protocols
TinyOS 2.0 provides simple reference implementations of two of the most basic protocols used in mote networks: dissemination and collection. Dissemination reliably delivers small (fewer than 20 byte) data items to every node in a network, while collection builds a routing tree rooted at a sink node. Together, these two protocols enable a wide range of data collection applications. Collection has advanced significantly since the most recent beta release; experimental tests in multiple network conditions have seen very high (>98%) deliver rates as long as the network is not saturated.
13. Conclusion
TinyOS 2.0 represents the next step of TinyOS development. Building on user experiences over the past few years, it has taken the basic TinyOS architecture and pushed it forward in several directions, hopefully leading to simpler and easier application development. It is still under active development: future prereleases will include non-volatile storage, basic multihop protocols (collection routing, dissemination), and further power management abstractions.
TinyOS 2.0 is a clean slate redesign and re-implementation of TinyOS. Its development was motivated by our belief that many aspects of 1.x strain to meet requirements and uses that were not foreseen when it was designed and implemented. The structure and interfaces 1.x defines have several fundamental limitations. While these limitations can be worked around, this practice has led to tightly coupled components, hard to find interactions, and a very steep learning curve for a newcomer to sensor network programming.
TinyOS 2.0 is not backwards compatible with 1.x: code written for the latter will not compile for the former. However, one important aspect of 2.0's design is to minimize the difficulty of upgrading code. Therefore, while porting a 1.x application to 2.0 will require some work, it should not be very much.
This document provides a high-level overview of 2.0 and describes some of the ways in which it departs from 1.x. It covers the basic TinyOS abstractions, such as hardware abstractions, communication, timers, the scheduler, booting and initialization. Further detail on each of these can be found in TEPs (TinyOS Enhancement Proposals), which document and describe these abstractions.
2. Platforms/Hardware Abstraction
Platforms exist in the tos/platforms subdirectory. In TinyOS 2.0, a platform is a collection of chips and some glue code that connects them together. For example, the mica2 platform is the CC1000 radio chip and the ATmega128 microcontroller, while the micaZ platform is the CC2420 radio and the ATmega128 microcontroller, and the Teloi platforms are the CC2420 radio and the MSP430 microcontroller. Chip code exists in tos/chips. A platform directory generally has a .platform file, which has options to pass to the nesC compiler. For example, the mica2 .platform file tells ncc to look in chips/cc1000 and chips/atm128 directories, as well as to use avr-gcc to compile a mote binary (Teloi platforms tell it to use msp430-gcc).
Hardware abstractions in TinyOS 2.0 generally follow a three-level abstaction heirarchy, called the HAA (Hardware Abstraction Architecture).
At the bottom of the HAA is the HPL (Hardware Presentation Layer). The HPL is a thin software layer on top of the raw hardware, presenting hardare such as IO pins or registers as nesC interfaces. The HPL generally has no state besides the hardware itself (it has no variables). HPL components usually have the prefix Hpl, followed by the name of the chip. For example, the HPL components of the CC1000 begin with HplCC1000.
The middle of the HAA is the HAL (Hardware Abstraction Layer). The HAL builds on top of the HPL and provides higher-level abstractions that are easier to use than the HPL but still provide the full functionality of the underlying hardware. The HAL components usually have a prefix of the chip name. For example, the HAL components of the CC1000 begin with CC1000.
The top of the HAA is the HIL (Hardware Independent Layer). The HIL builds on top of the HAL and provides abstractions that are hardware independent. This generalization means that the HIL usually does not provide all of the functionality that the HAL can. HIL components have no naming prefix, as they represent abstractions that applications can use and safely compile on multiple platforms. For example, the HIL component of the CC1000 on the mica2 is ActiveMessageC, representing a full active message communication layer.
The HAA is described in TEP 2: Hardware Abstraction Architecture[TEP2].
Currently (as of the 2.0 release in November 2006), TinyOS 2.0 supports the following platforms:
•eyesIFXv2
•intelmote2
•mica2
•mica2dot
•micaZ
•telosb
•tinynode
•btnode3
The btnode3 platform is not included in the RPM.
3. Scheduler
As with TinyOS 1.x, TinyOS 2.0 scheduler has a non-preemptive FIFO policy. However, tasks in 2.0 operate slightly differently than in 1.x.
In TinyOS 1.x, there is a shared task queue for all tasks, and a component can post a task multiple times. If the task queue is full, the post operation fails. Experience with networking stacks showed this to be problematic, as the task might signal completion of a split-phase operation: if the post fails, the component above might block forever, waiting for the completion event.
In TinyOS 2.x, every task has its own reserved slot in the task queue, and a task can only be posted once. A post fails if and only if the task has already been posted. If a component needs to post a task multiple times, it can set an internal state variable so that when the task executes, it reposts itself.
This slight change in semantics greatly simplifies a lot of component code. Rather than test to see if a task is posted already before posting it, a component can just post the task. Components do not have to try to recover from failed posts and retry. The cost is one byte of state per task. Even in large systems such as TinyDB, this cost is under one hundred bytes (in TinyDB is is approximately 50).
Applications can also replace the scheduler, if they wish. This allows programmers to try new scheduling policies, such as priority- or deadline-based. It is important to maintain non-preemptiveness, however, or the scheduler will break all nesC's static concurrency analysis. Details on the new scheduler and how to extend it can be found in TEP 106: Schedulers and Tasks[TEP106].
4. Booting/Initialization
TinyOS 2.0 has a different boot sequence than 1.x. The 1.x interface StdControl has been split into two interfaces: Init and StdControl. The latter only has two commands: start and stop. In TinyOS 1.x, wiring components to the boot sequence would cause them to be powered up and started at boot. That is no longer the case: the boot sequence only initializes components. When it has completed initializing the scheduler, hardware, and software, the boot sequence signals the Boot.booted event. The top-level application component handles this event and start services accordingly. Details on the new boot sequence can be found in TEP 107: TinyOS 2.x Boot Sequence[TEP107].
5. Virtualization
TinyOS 2.0 is written with nesC 1.2, which introduces the concept of a 'generic' or instantiable component. Generic modules allow TinyOS to have reusable data structures, such as bit vectors and queues, which simplify development. More importantly, generic configurations allow services to encapsulate complex wiring relationships for clients that need them.
In practice, this means that many basic TinyOS services are now virtualized. Rather than wire to a component with a parameterized interface (e.g., GenericComm or TimerC in 1.x), a program instantiates a service component that provides the needed interface. This service component does all of the wiring underneath (e.g., in the case of timers, to a unique) automatically, reducing wiring mistakes and simplifying use of the abstraction.
6. Timers
TinyOS 2.0 provides a much richer set of timer interfaces than 1.x. Experience has shown that timers are one of the most critical abstractions a mote OS can provide, and so 2.0 expands the fidelity and form that timers take. Depending on the hardware resources of a platform, a component can use 32KHz as well as millisecond granularity timers, and the timer system may provide one or two high-precision timers that fire asynchronously (they have the async keyword). Components can query their timers for how much time remainins before they fire, and can start timers in the future (e.g., 'start firing a timer at 1Hz starting 31ms from now'). TEP 102: Timers[TEP102] defines what HIL components a platform must provide in order to support standard TinyOS timers. Platforms are required to provide millisecond granularity timers, and can provide finer granularity timers (e.g., 32kHz) if needed.
Timers present a good example of virtualization in 2.0. In 1.x, a program instantiates a timer by wiring to TimerC:
components App, TimerC;
App.Timer -> TimerC.Timer[unique("Timer")];
In 2.0, a program instantiates a timer:
components App, new TimerMilliC();
App.Timer -> TimerMilliC;
7. Communication
In TinyOS 2.0, the message buffer type is message_t, and it is a buffer that is large enough to hold a packet from any of a node's communication interfaces. The structure itself is completely opaque: components cannot reference its fields. Instead, all buffer accesses go through interfaces. For example, to get the destination address of an AM packet named msg, a component calls AMPacket.destination(msg).
Send interfaces distinguish the addressing mode of communication abstractions. For example, active message communication has the AMSend interface, as sending a packet require an AM destination address. In contrast, broadcasting and collection tree abstractions have the address-free Send interface.
Active messages are the network HIL. A platform's ActiveMessageC component defines which network interface is the standard communication medium. For example, a mica2 defines the CC1000 active message layer as ActiveMessageC, while the TMote defines the CC2420 active message layer as ActiveMessageC.
There is no longer a TOS_UART_ADDRESS for active message communication. Instead, a component should wire to SerialActiveMessageC, which provides active message communication over the serial port.
Active message communication is virtualized through four generic components, which take the AM type as a parameter: AMSenderC, AMReceiverC, AMSnooperC, and AMSnoopingReceiverC. AMSenderC is virtualized in that the call to send() does not fail if some other component is sending (as it does with GenericComm in 1.x). Instead, it fails only if that particular AMSenderC already has a packet outstanding or if the radio is not in a sending state. Underneath, the active message system queues and sends these outstanding packets. This is different than the QueuedSendC approach of 1.x, in which there is an N-deep queue that is shared among all senders. With N AMSenderC components, there is an N-deep queue where each sender has a single reserved entry. This means that each AMSenderC receives 1/n of the available post-MAC transmission opportunities, where n is the number of AMSenderC components with outstanding packets. In the worst case, n is the number of components; even when every protocol and component that sends packets is trying to send a packet, each one will receive its fair share of transmission opportunities.
Further information on message_t can be found in TEP 111: message_t[TEP111], while further information on AM can be found in TEP 116: Packet Protocols[TEP116].
The current TinyOS release has a low-power stack for the CC1000 radio (mica2 platform) and an experimental low-power stack for the CC2420 radio (micaz, telosb, and intelmote2 platforms).
8. Sensors
In TinyOS 2.0, named sensor components comprise the HIL of a platform's sensors. TEP 114 describes a set of HIL data acquisition interfaces, such as Read, ReadStream, and Get, which sensors provide according to their acquisition capabilities.
If a component needs high-frequency or very accurate sampling, it must use the HAL, which gives it the full power of the underlying platform (highly accurate platform-independent sampling is not really feasible, due to the particulars of individual platforms). Read assumes that the request can tolerate some latencies (for example, it might schedule competing requests using a FIFO policy).
Details on the ADC subsystem can be found in TEP 101: Analog-to-Digital Converters[TEP101]; details on the organization of sensor boards can be found in TEP 109: Sensorboards[TEP109], and the details of the HIL sensor interfaces can be found in TEP 114: Source and Sink Independent Drivers[TEP114].
9. Error Codes
The standard TinyOS 1.x return code is result_t, whose value is either SUCCESS (a non-zero value) or FAIL (a zero value). While this makes conditionals on calls very easy to write (e.g., if (call A.b())), it does not allow the callee to distinguish causes of error to the caller. In TinyOS 2.0, result_t is replaced by error_t, whose values include SUCCESS, FAIL, EBUSY, and ECANCEL. Interface commands and events define which error codes they may return and why.
From the perspective of porting code, this is the most significant different in 2.0. Calls that were once:
if (call X.y()) {
busy = TRUE;
}
now have their meanings reversed. In 1.x, the busy statement will execute if the call succeeds, while in 2.0 it will execute if the call fails. This encourages a more portable, upgradable, and readable approach:
if (call X.y() == SUCCESS) {
busy = TRUE;
}
10. Arbitration
While basic abstractions, such as packet communication and timers, can be virtualized, experiences with 1.x showed that some cannot without either adding significant complexity or limiting the system. The most pressing example of this is a shared bus on a microcontroller. Many different systems -- sensors, storage, the radio -- might need to use the bus at the same time, so some way of arbitrating access is needed.
To support these kinds of abstractions, TinyOS 2.0 introduces the Resource interface, which components use to request and acquire shared resources, and arbiters, which provide a policy for arbitrating access between multiple clients. For some abstractions, the arbiter also provides a power management policy, as it can tell when the system is no longer needed and can be safely turned off.
TEP 108: Resource Arbitration[TEP108] describes the Resource interface and how arbiters work.
11. Power Management
Power management in 2.0 is divided into two parts: the power state of the microcontroller and the power state of devices. The former, discussed in TEP 112: Microcontroller Power Management[TEP112], is computed in a chip-specific manner by examining which devices and interrupt souces are active. The latter, discussed in TEP 115: Power Management of Non-Virtualised Devices{TEP115], is handled through resource abiters. Fully virtualized services have their own, individual power management policies.
TinyOS 2.0 provides low-power stacks for the CC1000 (mica2) and CC2420 (micaz, telosb, imote2) radios. Both use a low-power listening apporach, where transmitters send long preambles or repeatedly send packets and receivers wake up periodically to sense the channel to hear if there is a packet being transmitted. The low-power stack CC1000 is standard, while the CC2420 stack is experimental. That is, the default CC1000 stack (chips/cc1000) has low-power-listening, while the default CC2420 stack (chips/cc2420) does not. To use the low-power CC2420 stack, you must include chips/cc2420_lpl in your application Makefile.
12. Network Protocols
TinyOS 2.0 provides simple reference implementations of two of the most basic protocols used in mote networks: dissemination and collection. Dissemination reliably delivers small (fewer than 20 byte) data items to every node in a network, while collection builds a routing tree rooted at a sink node. Together, these two protocols enable a wide range of data collection applications. Collection has advanced significantly since the most recent beta release; experimental tests in multiple network conditions have seen very high (>98%) deliver rates as long as the network is not saturated.
13. Conclusion
TinyOS 2.0 represents the next step of TinyOS development. Building on user experiences over the past few years, it has taken the basic TinyOS architecture and pushed it forward in several directions, hopefully leading to simpler and easier application development. It is still under active development: future prereleases will include non-volatile storage, basic multihop protocols (collection routing, dissemination), and further power management abstractions.
xubuntu network 설정
처음 xubuntu를 설치하게 되면 dhcp로 IP가 할당된다.
수동으로 고정 IP를 설정하기 위해서는
# vim /etc/networking/interfaces 파일의 내용을 다음과 같이 변경한다.
# iface eth0 inet dhcp 부분을 주석처리하고,
iface eth0 inet static
address 192.168.100.xxx
netmask 255.255.255.0
network 192.168.xxx.xxx
broadcast 192.168.xxx.xxx
gateway 192.168.xxx.xxx
위와 같이 설정이 끝나면 네트워킹을 재시작한다.
# sudo /etc/init.d/networking restart
변경된 IP 주소를 확인한다.
# ifconfig
수동으로 고정 IP를 설정하기 위해서는
# vim /etc/networking/interfaces 파일의 내용을 다음과 같이 변경한다.
# iface eth0 inet dhcp 부분을 주석처리하고,
iface eth0 inet static
address 192.168.100.xxx
netmask 255.255.255.0
network 192.168.xxx.xxx
broadcast 192.168.xxx.xxx
gateway 192.168.xxx.xxx
위와 같이 설정이 끝나면 네트워킹을 재시작한다.
# sudo /etc/init.d/networking restart
변경된 IP 주소를 확인한다.
# ifconfig
xubuntu에 ssh 설치
1. ssh 설치
# sudo apt-get install ssh
2. 재시작
# sudo /etc/init.d/ssh restart
3. 확인
# netstat -ntl
# sudo apt-get install ssh
2. 재시작
# sudo /etc/init.d/ssh restart
3. 확인
# netstat -ntl
xubuntu에 samba 설치
우분투에서 samba를 이용하여 파일공유가 가능하다.
1. 파일 공유를 위한 서버에서 다음과 같이 samba package를 설치한다.
# sudo apt-get install samba smbfs
2. 접근할 ID와 비밀번호를 설정.
# sudo smbpasswd -a ID
3. samba 설정
# sudo vim /etc/samba/smb.conf
# 기본적인 설정
[global]
# 워크 그룹
workgroup = WORKGROUP
encrypt passwords = yes
# 접근 아이피 범위
hosts allow = 192.168.
# 문자 인코딩 설정, 우분투는 utf-8을 기본적으로
unix charset=utf-8
dos charset=utf-8
#공유 디렉토리 이름
[MyDoc]
comment = My Documents
path = /공유할/디렉토리/위치
#접근 설정 여부
read only = no
browsable = yes
등등... 필요한 내용을 입력한다.
ex)
# access IP address
[global]
host allow = 192.168
# authentication
[authentication]
security = user
# shared forder
[tinyos]
comment = xubuntu
path = /share
public = yes
available = yes
writeable = yes
create make = 0777
directory mask = 0777
guest ok = no
browseable = yes
4. 설정이 완료되면 재시작한다.
# sudo /etc/init.d/samba restart
the END.
1. 파일 공유를 위한 서버에서 다음과 같이 samba package를 설치한다.
# sudo apt-get install samba smbfs
2. 접근할 ID와 비밀번호를 설정.
# sudo smbpasswd -a ID
3. samba 설정
# sudo vim /etc/samba/smb.conf
# 기본적인 설정
[global]
# 워크 그룹
workgroup = WORKGROUP
encrypt passwords = yes
# 접근 아이피 범위
hosts allow = 192.168.
# 문자 인코딩 설정, 우분투는 utf-8을 기본적으로
unix charset=utf-8
dos charset=utf-8
#공유 디렉토리 이름
[MyDoc]
comment = My Documents
path = /공유할/디렉토리/위치
#접근 설정 여부
read only = no
browsable = yes
등등... 필요한 내용을 입력한다.
ex)
# access IP address
[global]
host allow = 192.168
# authentication
[authentication]
security = user
# shared forder
[tinyos]
comment = xubuntu
path = /share
public = yes
available = yes
writeable = yes
create make = 0777
directory mask = 0777
guest ok = no
browseable = yes
4. 설정이 완료되면 재시작한다.
# sudo /etc/init.d/samba restart
the END.
xubuntu에 APM 설치
xubuntu에서 APM의 설치는 의외로 간단하다.
1. apache2 설치
# sudo apt-get install apache2
2. php5 설치
# sudo apt-get install php5
3. mysql 설치
# sudo apt-get install mysql-server mysql-client
mysql과 php의 연동을 위해 다음과 같이 설치한다.
# sudo apt-get install php5-mysql
이상으로 기본적인 설치과정은 완료된다.
이제 apache 웹서버를 재시작한다.
# sudo /etc/init.d/apache2 restart
마찬가지로 mysql 서버도 재시작한다.
# sudo /etc/init.d/mysql restart
이로써 APM 환경이 구축된다.
1. apache2 설치
# sudo apt-get install apache2
2. php5 설치
# sudo apt-get install php5
3. mysql 설치
# sudo apt-get install mysql-server mysql-client
mysql과 php의 연동을 위해 다음과 같이 설치한다.
# sudo apt-get install php5-mysql
이상으로 기본적인 설치과정은 완료된다.
이제 apache 웹서버를 재시작한다.
# sudo /etc/init.d/apache2 restart
마찬가지로 mysql 서버도 재시작한다.
# sudo /etc/init.d/mysql restart
이로써 APM 환경이 구축된다.
2009년 5월 14일 목요일
Delta Application...
modified boomerang Delta application...
(voltage, humidity & temperature)
----------------------------------------
CommunicationsMoteiv’s communication system includes three main components: a Multihop mesh networkingprotocol, a network duty cycling protocol, and the recently proposed “Sensornet Protocol” (SP)abstraction for sending and receiving messages. All of these protocols are used in Moteiv’smesh networking application, Delta.
Multihop Networking
Moteiv’s on-demand ad-hoc networking utilizes spatial and temporal redundancy to reliabilitydeliver messages across a network to their destination. To use the Multihop library in anapplication, first include Multihop in your configuration:
Messages are submitted to the Multihop service and queued until there is an opportunity toroute the message towards the destination. After a message is successfully sent, an event(Send.sendDone()) is fired to your service notifying you that it is now safe to use themessage buffer for other purposes.
Low Power Operation
Moteiv’s software includes a synchronization protocol for low power wireless network. Thenetwork duty cycling approaches uses SP (described below) for establishing and maintaining aschedule whereby the entire network wakes up together and then returns to sleep.
Including Moteiv’s network duty cycling is as simple as adding a single parameter to thecompilation command. Simply add the lowpower keyword after the compilation platform. Forexample:
Information about Moteiv’s network duty cycling is included in the API documentation for theNetSyncC and NetWakeC components. The source is at /opt/moteiv/tos/lib/netsync;however we strongly recommend that only the most advanced users consider modifying thiscode. Please note that Moteiv does not support any modifications to our source.
Sensornet Protocol (SP)
SP is a unifying link abstraction for running network protocols over a variety of link layer andphysical layer technologies without changing network protocol implementation. SP isimplemented by the SPC component.
SPC and its interfaces are described in detail in the following publication:A Unifying Link Abstraction for Wireless Sensor NetworksIn Proceedings of the Third ACM Conference on Embedded Networked Sensor Systems(SenSys), November 2-4, 2005.
http://www.polastre.com/papers/sensys05-sp.pdf
Messages are transmitted using the SPSend interface and message futures are handledthrough the SPSendNext interface. To send a message on a particular AM type, such as AMtype 5, wire your network protocol to SPSend[5]. The SP message pool will hold on to amessage and its corresponding packets until it may be sent over the channel.
Fields of each SP message (sp_message_t) should never be directly accessed. Instead, theycan be set using the parameters of the SPSend interface. Reading parameters should be donethrough the SPMessage interface.
Reception is on a per packet basis (not a per message basis like SPSend). Packets areimmediately dispatched to higher layer services based on AM type. SPReceive providesinformation about each packet, including a token that identifies which interface a messageoriginated.
The SP Neighbor Table is accessed through the SPNeighbor interface. Users must wire to theSP Neighbor Table with the parameter unique("SPNeighbor"). Each service has its ownidentity for controlling the insertions, removals, and changes of entries in the SP NeighborTable. See the SPNeighbor interface in the API documentation for more information.
Various utilities as part of SP's processing are available in the SPUtil interface. These utilitiesinclude link estimation functions and link post-arbitration time stamps.
(voltage, humidity & temperature)
----------------------------------------
CommunicationsMoteiv’s communication system includes three main components: a Multihop mesh networkingprotocol, a network duty cycling protocol, and the recently proposed “Sensornet Protocol” (SP)abstraction for sending and receiving messages. All of these protocols are used in Moteiv’smesh networking application, Delta.
Multihop Networking
Moteiv’s on-demand ad-hoc networking utilizes spatial and temporal redundancy to reliabilitydeliver messages across a network to their destination. To use the Multihop library in anapplication, first include Multihop in your configuration:
- component Multihop;
- AppM.Send -> MultiHop.Send[APP_ID];
- APPM.Receive -> MultiHop.Receive[APP_ID];
Messages are submitted to the Multihop service and queued until there is an opportunity toroute the message towards the destination. After a message is successfully sent, an event(Send.sendDone()) is fired to your service notifying you that it is now safe to use themessage buffer for other purposes.
Low Power Operation
Moteiv’s software includes a synchronization protocol for low power wireless network. Thenetwork duty cycling approaches uses SP (described below) for establishing and maintaining aschedule whereby the entire network wakes up together and then returns to sleep.
Including Moteiv’s network duty cycling is as simple as adding a single parameter to thecompilation command. Simply add the lowpower keyword after the compilation platform. Forexample:
- make tmote lowpower
- cd /opt/tinyos-1.x/contrib/boomerang/apps/Delta
- make tmote lowpower
Information about Moteiv’s network duty cycling is included in the API documentation for theNetSyncC and NetWakeC components. The source is at /opt/moteiv/tos/lib/netsync;however we strongly recommend that only the most advanced users consider modifying thiscode. Please note that Moteiv does not support any modifications to our source.
Sensornet Protocol (SP)
SP is a unifying link abstraction for running network protocols over a variety of link layer andphysical layer technologies without changing network protocol implementation. SP isimplemented by the SPC component.
SPC and its interfaces are described in detail in the following publication:A Unifying Link Abstraction for Wireless Sensor NetworksIn Proceedings of the Third ACM Conference on Embedded Networked Sensor Systems(SenSys), November 2-4, 2005.
http://www.polastre.com/papers/sensys05-sp.pdf
Messages are transmitted using the SPSend interface and message futures are handledthrough the SPSendNext interface. To send a message on a particular AM type, such as AMtype 5, wire your network protocol to SPSend[5]. The SP message pool will hold on to amessage and its corresponding packets until it may be sent over the channel.
Fields of each SP message (sp_message_t) should never be directly accessed. Instead, theycan be set using the parameters of the SPSend interface. Reading parameters should be donethrough the SPMessage interface.
Reception is on a per packet basis (not a per message basis like SPSend). Packets areimmediately dispatched to higher layer services based on AM type. SPReceive providesinformation about each packet, including a token that identifies which interface a messageoriginated.
The SP Neighbor Table is accessed through the SPNeighbor interface. Users must wire to theSP Neighbor Table with the parameter unique("SPNeighbor"). Each service has its ownidentity for controlling the insertions, removals, and changes of entries in the SP NeighborTable. See the SPNeighbor interface in the API documentation for more information.
Various utilities as part of SP's processing are available in the SPUtil interface. These utilitiesinclude link estimation functions and link post-arbitration time stamps.
- moteiv corp -
Power Characteristic
Basic Sensor Node
* AA Size battery 2ea
* USB 전원 인가하여 사용 가능
* CC2420은 DC 2.1v ~ 3.6v 범위에서 동작
* MSP430F1611 MCU는 1.8v ~ 3.6v 범위에서 동작
* USB 연결로 programming시 최소 2.7v 전원이 필요
* PC의 USB 인터페이스로부터 받은 5v 전원을 Regulator를 이용하여 3v 로 전환
* AA Size battery 2ea
* USB 전원 인가하여 사용 가능
* CC2420은 DC 2.1v ~ 3.6v 범위에서 동작
* MSP430F1611 MCU는 1.8v ~ 3.6v 범위에서 동작
* USB 연결로 programming시 최소 2.7v 전원이 필요
* PC의 USB 인터페이스로부터 받은 5v 전원을 Regulator를 이용하여 3v 로 전환
2009년 5월 7일 목요일
TinyOS-1.x and Boomerang
TinyOS-1.x and Boomerang
These installation instructions will only work on Windows XP and XubuntOS. In particular, they will not work on Windows Vista, nor Mac OS. It is possible to install the tmote tools on any distribution of linux, but it is a bit more involved. XubuntOS makes your life a lot easier. The following is loosely based on http://www.5secondfuse.com/tinyos/oldInstall.html. I just added a few lines to the .bash_tinyos script to implement the boomerang function.
Installation
Windows XP
To install on XP, you need the Boomerang tmote tools CD, which you can get from me, or download from http://www.ccs.neu.edu/home/acassola/tmote-tools-2_0_4.zip.
To start, run the setup.msi file from within windows. The installer will set up Cygwin, Java5, TinyOS, and the boomerang/tmote-tools for you. To work, you will need to open a cygwin shell window. The installer made sure all the software and variables have been set.
XubuntOS
If you are using anything other than windows XP, you will need access to a trial version of VMWare workstation from http://www.vmware.com/, and download the XubuntOS virtual machine image at http://www.5secondfuse.com/tinyos/xubuntos-2.0-vm.tar.gz.
XubuntOS is a modified ubuntu installation that runs the XFCE window manager and has installed (almost) all the required java and TinyOS components for us.
Now follow these steps:
1. After unpacking the image, open it with vmware. Go to the VM->Settings Menu Option and under USB Controller check the box ``Automatically Connect USB Devices to this virtual machine. Click on Save.
2. Start the xubunTOS virtual machine. Once the machine is up, you can login with username xubuntos and password tinyos.
3. Go to Applications->System->Synaptic Package Manager. Click on the Reload Button. Click on the Search button and enter msp430 in the box and click search. Select the msp430-tinyos package, version 2.1-20080806 for installation, and accept the next dialog. Click on the apply button, and apply the next dialog, too.
4. Click on the terminal icon (next to the firefox icon). Inside the terminal run the following command:
wget -O .bash_tinyos http://www.ccs.neu.edu/home/acassola/bash_tinyos
5. Download the tinyos-tools zip file by running
wget http://www.ccs.neu.edu/home/acassola/tmote-tools-2_0_4.zip
in the same terminal as above
6. Download the moteiv tools package and install it. Change the owner of the installation directory:
wget http://www.ccs.neu.edu/home/acassola/tinyos-moteiv_2.0.4-2_all.deb
sudo dpkg --install *.deb
**Type the tinyos password**
sudo chown -R xubuntos /opt/moteiv
7. You are all set. Exit the terminal you were using, open the Qickstart guide inside the tools CD, read it, and start playing. Check out the tinyos tutorials available in the internet.
To interact with the motes, you need to use a terminal. Opening a new terminal after completing these instructions will give you one that has all its environment variables set to the right values and is ready to work.
These installation instructions will only work on Windows XP and XubuntOS. In particular, they will not work on Windows Vista, nor Mac OS. It is possible to install the tmote tools on any distribution of linux, but it is a bit more involved. XubuntOS makes your life a lot easier. The following is loosely based on http://www.5secondfuse.com/tinyos/oldInstall.html. I just added a few lines to the .bash_tinyos script to implement the boomerang function.
Installation
Windows XP
To install on XP, you need the Boomerang tmote tools CD, which you can get from me, or download from http://www.ccs.neu.edu/home/acassola/tmote-tools-2_0_4.zip.
To start, run the setup.msi file from within windows. The installer will set up Cygwin, Java5, TinyOS, and the boomerang/tmote-tools for you. To work, you will need to open a cygwin shell window. The installer made sure all the software and variables have been set.
XubuntOS
If you are using anything other than windows XP, you will need access to a trial version of VMWare workstation from http://www.vmware.com/, and download the XubuntOS virtual machine image at http://www.5secondfuse.com/tinyos/xubuntos-2.0-vm.tar.gz.
XubuntOS is a modified ubuntu installation that runs the XFCE window manager and has installed (almost) all the required java and TinyOS components for us.
Now follow these steps:
1. After unpacking the image, open it with vmware. Go to the VM->Settings Menu Option and under USB Controller check the box ``Automatically Connect USB Devices to this virtual machine. Click on Save.
2. Start the xubunTOS virtual machine. Once the machine is up, you can login with username xubuntos and password tinyos.
3. Go to Applications->System->Synaptic Package Manager. Click on the Reload Button. Click on the Search button and enter msp430 in the box and click search. Select the msp430-tinyos package, version 2.1-20080806 for installation, and accept the next dialog. Click on the apply button, and apply the next dialog, too.
4. Click on the terminal icon (next to the firefox icon). Inside the terminal run the following command:
wget -O .bash_tinyos http://www.ccs.neu.edu/home/acassola/bash_tinyos
5. Download the tinyos-tools zip file by running
wget http://www.ccs.neu.edu/home/acassola/tmote-tools-2_0_4.zip
in the same terminal as above
6. Download the moteiv tools package and install it. Change the owner of the installation directory:
wget http://www.ccs.neu.edu/home/acassola/tinyos-moteiv_2.0.4-2_all.deb
sudo dpkg --install *.deb
**Type the tinyos password**
sudo chown -R xubuntos /opt/moteiv
7. You are all set. Exit the terminal you were using, open the Qickstart guide inside the tools CD, read it, and start playing. Check out the tinyos tutorials available in the internet.
To interact with the motes, you need to use a terminal. Opening a new terminal after completing these instructions will give you one that has all its environment variables set to the right values and is ready to work.
- http://www.ccs.neu.deu/home/acassola/installtos/ -
Oscilloscope 어플리케이션 되짚어 보기.
Oscilloscope 어플리케이션 예제에서는 센싱 데이터가 2바이트씩 10개의 값을 보내도록 구현되어 있다. OscopeMsg 패킷의 형식을 보면 버퍼 사이즈 즉, 샘플링 데이터를 10개 수집하도록 되어 있기 때문이다. 하나씩 뜯어보도록 하자.
Tinyos에서 기본적으로 사용되는 TOS_Msg를 살펴보면
(/opt/tinyos-1.x/tos/platform/telos/AM.h)
#define TOSH_DATA_LENGTH 28
typedef struct TOS_Msg{
uint8_t length;
uint8_t fcfhi;
uint8_t fcflo;
uint8_t dsn;
uint16_t destpan;
uint16_t addr;
uint8_t type;
uint8_t group;
uint8_t data[TOSH_DATA_LENGTH];
uint16_t strength;
uint8_t lqi;
bool crc;
bool ack;
uint16_t time;
} TOS_Msg;
여기서 데이터가 저장되는 페이로드 부분은 int8_t data[TOSH_DATA_LENGTH]; 부분으로 총 28바이트의 크기를 가진다.
그리고 Oscilloscope에서 사용되는 OscopeMsg의 경우 TOS_Msg의 이 페이로드 부분, 즉 28바이트 크기를 가지는 data부분에 실려서 전송되며 별도의 헤더를 가진다.
enum {
BUFFER_SIZE = 10
};
struct OscopeMsg {
uint16_t sourceMoteID;
uint16_t lastSampleNumber;
uint16_t channel;
uint16_t data[BUFFER_SIZE];
} OscopeMsg;
총 28byte의 페이로드 중 6바이트를 OscopeMsg의 헤더로 사용하고 BUFFER_SIZE 크기 만큼인 20byte를 2바이트씩 10개의 데이터로 채운다. 즉, OscopeMsg 형태의 패킷을 사용하면 2바이트짜리 데이터가 패킷당 10개씩 들어오는 것이다.
왜 2바이트짜리를 사용하는가. 그것은 센서 노드에서 10~12bits의 ADC를 사용하기 때문이다. 즉, ADC를 거쳐 아날로그에서 디지털로 변환된 데이터의 크기는 10~12bits이고 이를 저장하기 위해서는 2바이트가 필요한 것이다. ADC에서 데이터를 변환하여 결과값이 나왔을때 호출되는 함수를 보면 async event result_t ADC.dataReady(uint16_t data); 와 같은 형식을 취하는데 인수로 넘어오는 uint16_t data가 ADC의 결과가 된다. 이 값을 보내기 위해서 당연히 2바이트 짜리 변수를 사용해서 보내는 것이다.
[TIP]
OscopeC 컴포넌트는 /opt/tinyos-1.x/tos/lib/Oscope에 위치해 있으며, 이 컴포넌트를 이용하여 (OscopeM.nc, Oscope.h와 함께) Oscilloscope에서 발생한 센서 데이터들을 센서 타입별로 OscopeMsg 형태로 만들어 RF로 전송하는 기능을 가진 컴포넌트이다.
/opt/tinyos-1.x/apps에 있는 Oscilloscope 어플리케이션은 오직 하나의 센서에 대해서만 처리하기 때문에 앞에서와 같은 기능 분리가 필요 없으나, /contrib/moteiv/apps에 있는 Oscilloscope 어플리케이션은 여러 개의 센서들에 대해서 샘플링하고, 이를 각각 OscopeMsg로 만들어서 전달하여야 하므로 위와 같은 기능을 분리한 것이다. 물론 사용자 어플리케이션에서 모든 것을 처리할 수도 있겠지만, 같은 것의 반복을 parameterized 인터페이스를 통해 좀 더 간결하고 쉽게 해결하기 위해 OscopeC 컴포넌트를 사용한다.
Tinyos에서 기본적으로 사용되는 TOS_Msg를 살펴보면
(/opt/tinyos-1.x/tos/platform/telos/AM.h)
#define TOSH_DATA_LENGTH 28
typedef struct TOS_Msg{
uint8_t length;
uint8_t fcfhi;
uint8_t fcflo;
uint8_t dsn;
uint16_t destpan;
uint16_t addr;
uint8_t type;
uint8_t group;
uint8_t data[TOSH_DATA_LENGTH];
uint16_t strength;
uint8_t lqi;
bool crc;
bool ack;
uint16_t time;
} TOS_Msg;
여기서 데이터가 저장되는 페이로드 부분은 int8_t data[TOSH_DATA_LENGTH]; 부분으로 총 28바이트의 크기를 가진다.
그리고 Oscilloscope에서 사용되는 OscopeMsg의 경우 TOS_Msg의 이 페이로드 부분, 즉 28바이트 크기를 가지는 data부분에 실려서 전송되며 별도의 헤더를 가진다.
enum {
BUFFER_SIZE = 10
};
struct OscopeMsg {
uint16_t sourceMoteID;
uint16_t lastSampleNumber;
uint16_t channel;
uint16_t data[BUFFER_SIZE];
} OscopeMsg;
총 28byte의 페이로드 중 6바이트를 OscopeMsg의 헤더로 사용하고 BUFFER_SIZE 크기 만큼인 20byte를 2바이트씩 10개의 데이터로 채운다. 즉, OscopeMsg 형태의 패킷을 사용하면 2바이트짜리 데이터가 패킷당 10개씩 들어오는 것이다.
왜 2바이트짜리를 사용하는가. 그것은 센서 노드에서 10~12bits의 ADC를 사용하기 때문이다. 즉, ADC를 거쳐 아날로그에서 디지털로 변환된 데이터의 크기는 10~12bits이고 이를 저장하기 위해서는 2바이트가 필요한 것이다. ADC에서 데이터를 변환하여 결과값이 나왔을때 호출되는 함수를 보면 async event result_t ADC.dataReady(uint16_t data); 와 같은 형식을 취하는데 인수로 넘어오는 uint16_t data가 ADC의 결과가 된다. 이 값을 보내기 위해서 당연히 2바이트 짜리 변수를 사용해서 보내는 것이다.
[TIP]
OscopeC 컴포넌트는 /opt/tinyos-1.x/tos/lib/Oscope에 위치해 있으며, 이 컴포넌트를 이용하여 (OscopeM.nc, Oscope.h와 함께) Oscilloscope에서 발생한 센서 데이터들을 센서 타입별로 OscopeMsg 형태로 만들어 RF로 전송하는 기능을 가진 컴포넌트이다.
/opt/tinyos-1.x/apps에 있는 Oscilloscope 어플리케이션은 오직 하나의 센서에 대해서만 처리하기 때문에 앞에서와 같은 기능 분리가 필요 없으나, /contrib/moteiv/apps에 있는 Oscilloscope 어플리케이션은 여러 개의 센서들에 대해서 샘플링하고, 이를 각각 OscopeMsg로 만들어서 전달하여야 하므로 위와 같은 기능을 분리한 것이다. 물론 사용자 어플리케이션에서 모든 것을 처리할 수도 있겠지만, 같은 것의 반복을 parameterized 인터페이스를 통해 좀 더 간결하고 쉽게 해결하기 위해 OscopeC 컴포넌트를 사용한다.
2009년 5월 3일 일요일
Makelocal
/opt/tinyos-1.x/tools/make/Makelocal 파일을 다음과 같이 설정하거나 또는, 해당 어플리케이션의 Makefile 내에 추가하면 컴파일 시 해당 내용이 적용된다.
#DEFAULT_LOCAL_GROUP = 0x7d
#PFLAGS += -DCC2420_DEF_CHANNEL = 26
#PFLAGS += -DDEFAULT_BAUDRATE = 57600
#PFLAGS += -DCC2420_DEF_RFPOWER = 31
또한, PFLAGS를 이용하여 경로 include 할 컴포넌트 및 라이브러리를 추가할 시, 다음과 같이 사용하면 된다.
#PFLAGS += -I$(TOSDIR)/../contrib/ucb/tos/lib/Oscope
참고로 크로스컴파일러 옵션의 -I는 include 폴더를 지정하는 것이며, -D는 define, 즉 컴파일전 정의를 해주는 것이다.
#PFLAGS += -v 옵션으로 해당 어플리케이션에서 사용하는 모든 파일을 컴파일 시간에 확인할 수 있다. 또한 컴파일 시 어플리케이션에의 참조 파일 목록을 텍스트 파일로 저장할 수도 있다.
# make telosb 2&>test.txt
#DEFAULT_LOCAL_GROUP = 0x7d
#PFLAGS += -DCC2420_DEF_CHANNEL = 26
#PFLAGS += -DDEFAULT_BAUDRATE = 57600
#PFLAGS += -DCC2420_DEF_RFPOWER = 31
또한, PFLAGS를 이용하여 경로 include 할 컴포넌트 및 라이브러리를 추가할 시, 다음과 같이 사용하면 된다.
#PFLAGS += -I$(TOSDIR)/../contrib/ucb/tos/lib/Oscope
참고로 크로스컴파일러 옵션의 -I는 include 폴더를 지정하는 것이며, -D는 define, 즉 컴파일전 정의를 해주는 것이다.
#PFLAGS += -v 옵션으로 해당 어플리케이션에서 사용하는 모든 파일을 컴파일 시간에 확인할 수 있다. 또한 컴파일 시 어플리케이션에의 참조 파일 목록을 텍스트 파일로 저장할 수도 있다.
# make telosb 2&>test.txt
2009년 5월 1일 금요일
Issue
* Low Power Listening *
Arch Rock에서 CC2420 기반의 Low Power Listening을 성공적으로 구현, 2007년 초부터 TinyOS-2.x에 LPL 코드가 공개되었다.
저 전력 통신을 위해서는 주기적으로 CC2420을 sleep/wake 동작이 가능하도록 해야 한다.
MAC 계층 에서 Telosb의 저 전력은 현재 많이 사용하는 SurgeTelos등과 같은 공개된 코드에서는 active 상태로 동작한다. CC2420은 active 상태에서는 20mA 이상의 전류가 항상 소모되고 있다. CC2420은 보통 17mA ~ 20mA 정도의 전력을 소비하므로 항상 wake 되어 있는 일반적인 SurgeTelos 등과 같은 어플리케이션의 경우 저 전력으로 동작시킬 수 없다.
저 전력을 구현하기 위해서는 TinyOS-2.x 의 LPL을 이용해야 한다. (tutorial 참조)
결론은 TinyOS-1.x 에서는 CC2420의 저 전력이 불가능하고, TinyOS-2.x 에서는 LPL이 지원되므로 저 전력으로 구현이 가능하다. 이 LPL은 Deluge를 구현한 Jonathan Hui가 만들었다. 현재 6LowPAN에서 왕성한 활동을 하고 있다.
CC1000 계열에서는 소프트웨어에서 Preamble을 제어 할 수 있다. CC2420은 보내고자하는 데이터를 버퍼로 입력해주면, 하드웨어가 알아서 전송한다. 즉, CC1000과 같이 세밀한 제어가 불가능 하다. CC2420은 대부분의 기능을 하드웨어가 하기 때문에, 새로운 알고리즘을 적용한 프로토콜을 만들어내기가 거의 불가능하다. 따라서 대부분의 학계 연구결과들은 CC1000을 기반으로 발표된 내용이며, S-MAC, PRIME, Funelling MAC 등 CC2420은 제약이 많다. 저 전력으로 구현하기에는 CC1000이 성능이 좋다. 그 이유는 Preamble을 가변적으로 조절해서 LPL을 구현할 수 있기 때문이다. CC2420은 데이터 전송률이 높으며, MCU와 연결하여 통신을 하기에 매우 편리하다. CC1000과 다르게 대부분의 기능을 하드웨어가 담당한다. 또한, CC2420은 IEEE 표준 기반이지만 CC1000은 아니다. 현재 비즈니스를 하는 대부분의 회사들은 표준을 따라 가고 있다. Vertical market은 한계를 가지고 있기 때문이다.
B-MAC은 ZigBee용 MAC이 아니다. 기본적으로 B-MAC은 CC1000 칩을 위한 MAC 프로토콜로 Preamble 을 동적으로 줄이고 늘이고 해야하기 때문에, CC2420에서는 불가능 하다. 보통 Telos 에 사용된 MAC을 LPL(Low Power Listening)이 없는 MAC이라고 부른다. 그동안의 Sensys 컨퍼런스 논문들을 보면, 센서 네트워크에서의 MAC이 어떻게 발전 되어 왔는지를 볼 수 있다. 그중 저전력을 목표로 구현한 것들이 많다. CC2420 칩이 20mA 정도를 항상 소비한다고 보면, 얼마나 잘 Sleep 시켰다가, wake up 시키느냐가 중요하다고 볼 수 있다.
Arch Rock에서 CC2420 기반의 Low Power Listening을 성공적으로 구현, 2007년 초부터 TinyOS-2.x에 LPL 코드가 공개되었다.
저 전력 통신을 위해서는 주기적으로 CC2420을 sleep/wake 동작이 가능하도록 해야 한다.
MAC 계층 에서 Telosb의 저 전력은 현재 많이 사용하는 SurgeTelos등과 같은 공개된 코드에서는 active 상태로 동작한다. CC2420은 active 상태에서는 20mA 이상의 전류가 항상 소모되고 있다. CC2420은 보통 17mA ~ 20mA 정도의 전력을 소비하므로 항상 wake 되어 있는 일반적인 SurgeTelos 등과 같은 어플리케이션의 경우 저 전력으로 동작시킬 수 없다.
저 전력을 구현하기 위해서는 TinyOS-2.x 의 LPL을 이용해야 한다. (tutorial 참조)
결론은 TinyOS-1.x 에서는 CC2420의 저 전력이 불가능하고, TinyOS-2.x 에서는 LPL이 지원되므로 저 전력으로 구현이 가능하다. 이 LPL은 Deluge를 구현한 Jonathan Hui가 만들었다. 현재 6LowPAN에서 왕성한 활동을 하고 있다.
CC1000 계열에서는 소프트웨어에서 Preamble을 제어 할 수 있다. CC2420은 보내고자하는 데이터를 버퍼로 입력해주면, 하드웨어가 알아서 전송한다. 즉, CC1000과 같이 세밀한 제어가 불가능 하다. CC2420은 대부분의 기능을 하드웨어가 하기 때문에, 새로운 알고리즘을 적용한 프로토콜을 만들어내기가 거의 불가능하다. 따라서 대부분의 학계 연구결과들은 CC1000을 기반으로 발표된 내용이며, S-MAC, PRIME, Funelling MAC 등 CC2420은 제약이 많다. 저 전력으로 구현하기에는 CC1000이 성능이 좋다. 그 이유는 Preamble을 가변적으로 조절해서 LPL을 구현할 수 있기 때문이다. CC2420은 데이터 전송률이 높으며, MCU와 연결하여 통신을 하기에 매우 편리하다. CC1000과 다르게 대부분의 기능을 하드웨어가 담당한다. 또한, CC2420은 IEEE 표준 기반이지만 CC1000은 아니다. 현재 비즈니스를 하는 대부분의 회사들은 표준을 따라 가고 있다. Vertical market은 한계를 가지고 있기 때문이다.
B-MAC은 ZigBee용 MAC이 아니다. 기본적으로 B-MAC은 CC1000 칩을 위한 MAC 프로토콜로 Preamble 을 동적으로 줄이고 늘이고 해야하기 때문에, CC2420에서는 불가능 하다. 보통 Telos 에 사용된 MAC을 LPL(Low Power Listening)이 없는 MAC이라고 부른다. 그동안의 Sensys 컨퍼런스 논문들을 보면, 센서 네트워크에서의 MAC이 어떻게 발전 되어 왔는지를 볼 수 있다. 그중 저전력을 목표로 구현한 것들이 많다. CC2420 칩이 20mA 정도를 항상 소비한다고 보면, 얼마나 잘 Sleep 시켰다가, wake up 시키느냐가 중요하다고 볼 수 있다.
- tinyos korea -
2009년 4월 25일 토요일
TinyOS Installation for Moteiv's Tmote Sky
TinyOS Installation for Moteiv's Tmote Sky
UPDATED: October 17, 2007
Shortcut: Now you could follow this install guide... Or you can download the LiveCD and make your life much easier. This guide is generic across Ubuntu/Kubuntu/Xubuntu and the CD is specifically for Xubuntu. It's really up to you. If you want it you can find it here or at a mirror. But I can tell you that the CD is great. Its what I use and everything works. You don't need to do anything. So by all means use it! It really is the fastest way to start working in wireless sensor networks.
If you just can't bring yourself to install over your Windows partition and rebooting into XubunTOS everytime you want to work on TinyOS is too much as well... Then you are in luck. Kevin Klues at Stanford has been nice enough to make a VMware image of XubunTOS which runs in VMware's free "Player" software. You can download the software here (User: xubuntos Passwd: tinyos). You can find a copy of the image here. Download it and and answer yes if it asks you to switch your floppy or CD-Rom.
I've updated the instructions to use Stanford's Ubuntu repository. These packages and instructions were specifically written for Fiesty Fawn (7.04) however with some simple path changes they should work (maybe/probably) for Edgy Eft or Breezy Badger
I referenced the following guides to install TinyOS:
http://moteiv.com/community/Tmote_Linux_install (Dead link)
http://www.comnets.uni-bremen.de/typo3site/index.php?id=48
http://www.tinyos.net/tinyos-2.x/doc/html/install-tinyos.html
I also stole heavily from Wade Simmons and his Toiler's version. Thanks Wade! Another big thank you to Leith Abdulla, the deb packager at Stanford. Leith has updated the Stanford msp430 toolchains to fix the previous problem where the TinyOS toolchain wouldn't compile all Boomerang apps.
This guide is specifically for getting Tmote Sky hardware from Moteiv to work. I don't have any other motes to test this against. That said this should generally work (I think) for other motes.
TinyOS 1.x: With every passing day I forget more and more about TinyOS 1.x. I don't use it and I don't recommend you use it unless you need a library/protocol/application that hasn't been ported. And even in that case, port it and move out of TinyOS 1.x. I only do a quick and dirty test of TinyOS 1.x and all you can be certain of is Blink and that the Java SDK works.
DISCLAIMER: This is how I got things working. I have seen many of the example applications working, TOSSIM, etc. But I haven't stressed tested anything. Your mileage may vary. Let me know if you find things working differently.
NOTE: Recently its come to my attention that a lot of people are using this guide. That's great. But please if you reference the guide in your own web pages include a link and don't just yank the content. Its just not cool.
Ubuntu Packages
In order to insure you have all the required packages, you'll need to add the universe and multiverse repositories for Fiesty. You'll also need to add Stanford's TinyOS repository.
First, as root, open the /etc/apt/sources.list file
Then add the universe, multiverse and Stanford repositories.
deb http://tinyos.stanford.edu/tinyos/dists/ubuntu edgy main
deb http://us.archive.ubuntu.com/ubuntu/ feisty main restricted
deb-src http://us.archive.ubuntu.com/ubuntu/ feisty main restricted
deb http://us.archive.ubuntu.com/ubuntu/ feisty-updates main restricted
deb-src http://us.archive.ubuntu.com/ubuntu/ feisty-updates main restricted
deb http://us.archive.ubuntu.com/ubuntu/ feisty universe
deb-src http://us.archive.ubuntu.com/ubuntu/ feisty universe
deb http://us.archive.ubuntu.com/ubuntu/ feisty multiverse
deb-src http://us.archive.ubuntu.com/ubuntu/ feisty multiverse
deb http://security.ubuntu.com/ubuntu feisty-security main restricted
deb-src http://security.ubuntu.com/ubuntu feisty-security main restricted
deb http://security.ubuntu.com/ubuntu feisty-security universe
deb-src http://security.ubuntu.com/ubuntu feisty-security universe
deb http://security.ubuntu.com/ubuntu feisty-security multiverse
deb-src http://security.ubuntu.com/ubuntu feisty-security multiverse
deb http://tinyos.stanford.edu/tinyos/dists/ubuntu feisty main
Now you just need to add the packages.
sudo apt-get install cvs subversion autoconf automake1.9 python-dev
sudo apt-get install g++ g++-3.4 gperf swig sun-java5-jdk graphviz alien fakeroot
sudo apt-get install tinyos-msp430 tinyos-avr
Environment Variables
This guide sets up your development environment so you can use TinyOS 1.x, TinyOS 2.x, and Boomerang. To make life easy you can download this file here and save it to your home directory. You'll need to add a line to your .bashrc to source this file on login. If you use a different shell it would be fairly trivial to change over.
# Add this to your .bashrc
if [ -f ~/.bash_tinyos ]; then
. ~/.bash_tinyos
fi
This will allow you to switch between environments on fly.
metcalfc@TinyLaptop:~$ tos1
Setting up for TinyOS 1.x
... Do TinyOS 1.x work ...
metcalfc@TinyLaptop:~$ tos2
Setting up for TinyOS 2.x ...
... Do TinyOS 2.x work
metcalfc@TinyLaptop:~$ boomerang
Setting up for TinyOS 1.x with Boomerang
... Do TinyOS Boomerang work ...
Install TinyOS 1.x
cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos login
cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co tinyos-1.x
sudo mv tinyos-1.x /opt
Install Boomerang
For the Moteiv specific Boomerang installation you'll need to get the files from... Someone who already has them. Moteiv is now Sentilla and they aren't supporting Boomerang.
mkdir tmote
cp tmote-tools-2_0_4.zip tmote
cd tmote
unzip tmote-tools-2_0_4.zip
cd common/rpms
fakeroot alien -d tinyos-moteiv-2.0.4-1.cygwin.noarch.rpm
sudo dpkg --install *.deb
cd ~
rm -rf tmote
sudo chown -R $USER /opt/moteiv
Optional: Install TinyOS from CVS
Most of the time I'm using TinyOS 2.x so I decided to use the bleeding edge from cvs. You can put it anywhere. I've chosen my home directory. You'll still have the official release in /opt. You'll also need to update your .bash_tinyos to reflect where you put it.
cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos login
cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co tinyos-2.x
cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co tinyos-2.x-contrib
Java Serial Communications for TinyOS 1.x
You'll need to install TOSComm in order for your TinyOS 1.x Java toolchain to work. Yes, the TinyOS-tools package from TinyOS 2.x does this but it doesn't work for 1.x. And yes the two can coexist in your $JDKROOT.
The installer detects the wrong location to install the files to because of the alternatives setup.
Edit the JAVADIR rule in the $TOSROOT/beta/TOSComm/comm/Makefile with: JAVADIR=/usr/lib/jvm/java-1.5.0-sun
Now install it. We'll alias g++ to the correct version so we don't have to edit anymore makefiles.
alias g++=g++-3.4; cd $TOSROOT/beta/TOSComm/comm; sudo make install
The End
UPDATED: October 17, 2007
Shortcut: Now you could follow this install guide... Or you can download the LiveCD and make your life much easier. This guide is generic across Ubuntu/Kubuntu/Xubuntu and the CD is specifically for Xubuntu. It's really up to you. If you want it you can find it here or at a mirror. But I can tell you that the CD is great. Its what I use and everything works. You don't need to do anything. So by all means use it! It really is the fastest way to start working in wireless sensor networks.
If you just can't bring yourself to install over your Windows partition and rebooting into XubunTOS everytime you want to work on TinyOS is too much as well... Then you are in luck. Kevin Klues at Stanford has been nice enough to make a VMware image of XubunTOS which runs in VMware's free "Player" software. You can download the software here (User: xubuntos Passwd: tinyos). You can find a copy of the image here. Download it and and answer yes if it asks you to switch your floppy or CD-Rom.
I've updated the instructions to use Stanford's Ubuntu repository. These packages and instructions were specifically written for Fiesty Fawn (7.04) however with some simple path changes they should work (maybe/probably) for Edgy Eft or Breezy Badger
I referenced the following guides to install TinyOS:
http://moteiv.com/community/Tmote_Linux_install (Dead link)
http://www.comnets.uni-bremen.de/typo3site/index.php?id=48
http://www.tinyos.net/tinyos-2.x/doc/html/install-tinyos.html
I also stole heavily from Wade Simmons and his Toiler's version. Thanks Wade! Another big thank you to Leith Abdulla, the deb packager at Stanford. Leith has updated the Stanford msp430 toolchains to fix the previous problem where the TinyOS toolchain wouldn't compile all Boomerang apps.
This guide is specifically for getting Tmote Sky hardware from Moteiv to work. I don't have any other motes to test this against. That said this should generally work (I think) for other motes.
TinyOS 1.x: With every passing day I forget more and more about TinyOS 1.x. I don't use it and I don't recommend you use it unless you need a library/protocol/application that hasn't been ported. And even in that case, port it and move out of TinyOS 1.x. I only do a quick and dirty test of TinyOS 1.x and all you can be certain of is Blink and that the Java SDK works.
DISCLAIMER: This is how I got things working. I have seen many of the example applications working, TOSSIM, etc. But I haven't stressed tested anything. Your mileage may vary. Let me know if you find things working differently.
NOTE: Recently its come to my attention that a lot of people are using this guide. That's great. But please if you reference the guide in your own web pages include a link and don't just yank the content. Its just not cool.
Ubuntu Packages
In order to insure you have all the required packages, you'll need to add the universe and multiverse repositories for Fiesty. You'll also need to add Stanford's TinyOS repository.
First, as root, open the /etc/apt/sources.list file
Then add the universe, multiverse and Stanford repositories.
deb http://tinyos.stanford.edu/tinyos/dists/ubuntu edgy main
deb http://us.archive.ubuntu.com/ubuntu/ feisty main restricted
deb-src http://us.archive.ubuntu.com/ubuntu/ feisty main restricted
deb http://us.archive.ubuntu.com/ubuntu/ feisty-updates main restricted
deb-src http://us.archive.ubuntu.com/ubuntu/ feisty-updates main restricted
deb http://us.archive.ubuntu.com/ubuntu/ feisty universe
deb-src http://us.archive.ubuntu.com/ubuntu/ feisty universe
deb http://us.archive.ubuntu.com/ubuntu/ feisty multiverse
deb-src http://us.archive.ubuntu.com/ubuntu/ feisty multiverse
deb http://security.ubuntu.com/ubuntu feisty-security main restricted
deb-src http://security.ubuntu.com/ubuntu feisty-security main restricted
deb http://security.ubuntu.com/ubuntu feisty-security universe
deb-src http://security.ubuntu.com/ubuntu feisty-security universe
deb http://security.ubuntu.com/ubuntu feisty-security multiverse
deb-src http://security.ubuntu.com/ubuntu feisty-security multiverse
deb http://tinyos.stanford.edu/tinyos/dists/ubuntu feisty main
Now you just need to add the packages.
sudo apt-get install cvs subversion autoconf automake1.9 python-dev
sudo apt-get install g++ g++-3.4 gperf swig sun-java5-jdk graphviz alien fakeroot
sudo apt-get install tinyos-msp430 tinyos-avr
Environment Variables
This guide sets up your development environment so you can use TinyOS 1.x, TinyOS 2.x, and Boomerang. To make life easy you can download this file here and save it to your home directory. You'll need to add a line to your .bashrc to source this file on login. If you use a different shell it would be fairly trivial to change over.
# Add this to your .bashrc
if [ -f ~/.bash_tinyos ]; then
. ~/.bash_tinyos
fi
This will allow you to switch between environments on fly.
metcalfc@TinyLaptop:~$ tos1
Setting up for TinyOS 1.x
... Do TinyOS 1.x work ...
metcalfc@TinyLaptop:~$ tos2
Setting up for TinyOS 2.x ...
... Do TinyOS 2.x work
metcalfc@TinyLaptop:~$ boomerang
Setting up for TinyOS 1.x with Boomerang
... Do TinyOS Boomerang work ...
Install TinyOS 1.x
cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos login
cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co tinyos-1.x
sudo mv tinyos-1.x /opt
Install Boomerang
For the Moteiv specific Boomerang installation you'll need to get the files from... Someone who already has them. Moteiv is now Sentilla and they aren't supporting Boomerang.
mkdir tmote
cp tmote-tools-2_0_4.zip tmote
cd tmote
unzip tmote-tools-2_0_4.zip
cd common/rpms
fakeroot alien -d tinyos-moteiv-2.0.4-1.cygwin.noarch.rpm
sudo dpkg --install *.deb
cd ~
rm -rf tmote
sudo chown -R $USER /opt/moteiv
Optional: Install TinyOS from CVS
Most of the time I'm using TinyOS 2.x so I decided to use the bleeding edge from cvs. You can put it anywhere. I've chosen my home directory. You'll still have the official release in /opt. You'll also need to update your .bash_tinyos to reflect where you put it.
cvs -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos login
cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co tinyos-2.x
cvs -z3 -d:pserver:anonymous@tinyos.cvs.sourceforge.net:/cvsroot/tinyos co tinyos-2.x-contrib
Java Serial Communications for TinyOS 1.x
You'll need to install TOSComm in order for your TinyOS 1.x Java toolchain to work. Yes, the TinyOS-tools package from TinyOS 2.x does this but it doesn't work for 1.x. And yes the two can coexist in your $JDKROOT.
The installer detects the wrong location to install the files to because of the alternatives setup.
Edit the JAVADIR rule in the $TOSROOT/beta/TOSComm/comm/Makefile with: JAVADIR=/usr/lib/jvm/java-1.5.0-sun
Now install it. We'll alias g++ to the correct version so we don't have to edit anymore makefiles.
alias g++=g++-3.4; cd $TOSROOT/beta/TOSComm/comm; sudo make install
The End
- 5secondfuse -
피드 구독하기:
덧글 (Atom)