TIDA-010003의 software system 분석

-
본 포스트는 다음 document를 정리한 것입니다.
http://www.ti.com/lit/ug/tidue96/tidue96.pdf
아래 ti training의 video도 참고하였습니다.
https://training.ti.com/wireless-network-challenges-and-solutions-smarter-grid-iot

기타 출처:
TI SimpleLink CC13x0 SDK README 파일
http://www.ktword.co.kr/abbr_view.php?m_temp1=400




TIDA-010003에서는 CC1310 보드 하나를 사용해서 end node를 구현한다.

이는 6LoWPAN mesh network working with FH MAC over sub-1GHz RF 이다.



이 system의 software 계층 구조는 다음과 같다.


application                           app_task
------------------                    ---------------------
UDP
IPv6   RPL                            tcpip_task
6LoWPAN
------------------                   ----------------------
middleware                         middleware_process
------------------                   ----------------------
TI-15.4 FH MAC                   TI-15.4 stack
TI-15.4 PHY 



먼저 TI-15.4 stack은 동작하는 frequency band랑 mode를 제공한다. 
이는 /Application/api_mac.h에 mode들이 제공되어 있고, 현재는 915MHz US frequency band를 사용하게끔 되어 있는데, 이는 /Application/subg/config.h에서 PHY ID를 setting할 수 있다. 

(PHY 계층이 뭔지 아직 잘 모르겠네 

 > IEEE 802.15.4는 OSI 모델의 PHY layer와 MAC layer를 정의하는 표준이다.

PHY는 wireless link connection을 정의한다. 예를 들면, modulation, frequency, power같은.
MAC은 data format을 정의한다.
MAC은 Media Access Control로, 여러 단말들이 공유 매체에 접근할 때 발생하는 충돌등을 제어한다. 

TI SimpleLink PHY supports IEEE 802.15.4g for 50-kbps frequency-shift keying(FSK) and  5-kbps long range mode라고 한다.)

그 다음으로 
<Middleware layer> middleware_process

이 친구는 TI-15.4 stack과 그 위 layer간의 interface 역할을 한다.

이 친구는 많은 일을 한다.

1. initiate TI-15.4 stack (initiate가 무슨 일을 하는건지는 코드를 봐야겠다)
2. 4가지 state들을 관장 (init, fh_sync, PA_done, joined)
3. FH synchronization 수행
4. TI-15.4 stack이나 mesh network에서 들어오는 packet들 관리 
5. message timeout 이나 통신 오류 handling
6. MAC-level keep alive mechanism 관리

대략 정리해보면 TI-15.4 stack과 mesh network를 연결시켜주는 역할을 하니까
먼저 TI-15.4 stack을 initialize하고, FH network에 join시켜서 networking이 가능하게끔 만들어 주는 것 같다. 그 외 기능들은 그 과정에서 필요한 오류 체크나 그런 것들을 위한 것인 것 같다.


그 다음으로 
<Network layer> tcpip_task

이 친구는 6LoWPAN, IPv6, RPL, UDP를 포함한다. 그래서 이 친구들을 지원하는 CONTIKI open source os를 기반으로 한다.

이 친구가 하는 일은 tcpip_task이고, 무엇을 하는지 좀 더 자세하게 알려면
/6lowpan/uip_rpl_task.c 에 들어가면 볼 수 있다.

대략적으로 보면, application과 lower stack으로 부터 mailbox를 통해 온 message를 처리한다. 



그 다음으로
<Application layer>  app_task

이 예제에서 제공하는 UDP application은 UDP polling application이랑 pushing application이다.

이 친구는 UDP socket을 연다. 
(이 시스템은 end node를 위한 것이기 때문에, UDP client를 연다고 볼 수 있다.)

그리고 UDP data transmission을 시작한다.

UDP application에 따라 UDP data의 initiator가 달라지는데,
UDP poll의 경우, root가 end node에게 poll message를 initiate하고
UDP push의 경우, 보낼 data가 있으면 end node가 data transmission을 initiate한다.

(여기서 UDP poll의 경우, root가 initiator이기 때문에 end node의 tracking parent가 제대로 인지, 그래서 FH network에 제대로 들어왔는지 체크하기 위해 keep alive frame을 사용한다.)

smart metering에서는 주로 UDP polling을 사용하고, CoAP에서는 polling(GET command), pushing(OBSERVE command) 둘다 섞어서 사용한다고 한다.




여기까지가 software architecture에 대한 설명이었다.

그리고 위에 middleware 쪽에서 언급되었던 4가지 state와 FH sync과정에 대해 좀더 설명해보고자 한다.

먼저 power가 들어오면 Jdllc_deviceState_init state로 들어가서 TI-15.4 stack의 initiate 과정이 이뤄진다.

고것이 끝나면 Jdllc_deviceState_fh_sync state로 들어간다.

FH synchronization은 FH network에 join하고, FH timing과 schedule을 동기화하는 과정이다.

TI-MAC은 WiSUN-FAN(Field Area Network)를 기반으로 한 mechanism을 사용하는데, 

이를 하기 위해 4가지의 command를 사용한다.

PAS (PAN Advertisement Solicit)
PA
PCS (PAN Configuration Solicit)
PC



먼저, 어떤 node가 속해 있는 FH network가 있을 것이다.

아직 end node는 그 network에 들어가지 못했기 때문에 그 node가 어떤 channel을 listening 하고 있는지 모른다.

(우리는 FCC band를 사용해서 총 129개의 channel을 사용한다.)


현재 FH network에 속해있는 node는 ch 2에 있다고 하면, 
일단 end node는 첫번째 channel 부터 마지막 channel까지, 모든 channel에게 PAS를 보낸다. 


이를 들은 node가 PAS에 대한 응답으로, ch 2를 통해 end node에게 PA를 보낸다.

scan period 동안 end node가 여러개의 channel로 부터 PA를 받으면, link-level metric에 따라 tracking parent를 선정한다

이 PA를 통해 end node는 FH timing과 schedule, PAN information with tracking parent를 업데이트 한다. (이 PAN information이 PIB인 것 같다.)

이제 hopping pattern을 알았으니 계속 ch 2에 있으면서 network discovery를 끝내기 위해서 PCS를 보낸다.

이에 대한 응답으로, node가 PC를 보낸다. 
이 안에는 channel hopping pattern 과 security key, 그리고 Group Transient Key (GTK) hash information이 들어 있다.
(PA는 unicast로, PC는 broadcast로 hopping pattern등을 보낸다는데 왜 그런지는 모르겠다)

그럼 이제 end node는 FH synchronization을 통해 FH network에 join하게 된거고,
이제 channel hoppping 패턴을 알았으니, 해당 network에 속한 node들과 data를 주고 받을 수 있게 되었다!!!!

그리고 join하게 되면서 end node는 identifier로 short address와 PAN ID를 받게 된다.

여기서 굳이 state로 나눠서 설명하자면,
init에서 fh_sync로 가면 FH synchronization이 시작되고, PA_done으로 간다. 여기서 PA를 받으면 joined로 가고, FH synchronization이 성공하고, RPL routing discovery를 하면 RPL-level joining이 성공하고 green LED가 켜진다.
(그럼 RPL routing이 mesh network의 tcpip_task에서 이뤄지는 건가?)



그리고 Trickle Algorithm parameter들을 통해 end node가 PAS를 보내는 시간 간격, PA를 받는 scan period 등을 조정할 수 있다. (/Application/middleware.h > keep alive에 대한 parameter들도 여기에 있다~)


여기서 이제 UDP poll application을 사용한다고 하면, root로부터 poll 메세지가 오면 그때에 end node가 data를 보낼 것이다.


댓글

댓글 쓰기

이 블로그의 인기 게시물

[ROS] ros 두 기계 연결하기 (networking). 개쉬움.

-
먼저 통신을 관장하는 master가 존재하고 통신을 하고자 하는 여러 기계 (노드) 들이 존재한다. $roscore 를 실행하면 몇몇 문장과 함께 command 창에서 ROS_MASTER_URI = x.x.x.x  이런 식으로 master의 주소를 볼 수 있다. (이 주소는 잠시 후에 다시 등장한다) *왜냐하면 roscore를 실행한다는 것이 master를 동작시킨다는 의미이기 때문이다. 이 master를 A master라고 하자. 이때 각 노드들은 정보를 요청(subscribe)하거나, 정보를 제공(publish)하는데 자신이 누구인지 master에게 알려주기 위해 (마치 자신의 이름처럼)" ROS_IP" 를 지정해주어야 한다. 이는 각 기계의 IP 주소로, 우분투에서는 (ROS는 우분투에서 동작한다) $ifconfig  를 통해 알 수 있다. (윈도우 cmd 창에서는 $ipconfig) 이걸 치면 보통  eth0 lo wlan0 뭐 이런게 나올텐데 각 기계가 연결된 lan에 따라 주소가 나온 것이다. eth0은 유선랜으로 연결되었을 때의 주소이고, lo는 local 로 그냥 자기 자신을 계속 loop calling? 하는거라 이 주소는 여기서는 쓸모 없다 wlan은 무선랜(wifi)로 연결되었을 때의 주소이다. 각 파트에서 inter address? 뭐 이런 부분이 각 기계의 주소라고 보면된다. 예를들어 기계1의 IP 주소가 196.120.0.15 가 나오면 $export ROS_IP=196.120.0.15 를 해줌으로써 자신의 IP를 알린다 그리고 A master를 쓰고 있다는 것을 나타내기 위해 $export ROS_MASTER_URI=http://202.190.0.1:11311 같이 master의 주소를 export한다. ( :11311  이부분은 특별하게 master의 주소를 설정해 주지 않는이상 기본으로 부여?되는 값이라고 한다. ) 다른 기계2의 IP 주소도 위와 같이 구해서 $export ROS_...
자세한 내용 보기

[ROS - rosserial] unable to sync with device 오류

-
이미지
일단 코드에 문제가 있는 것은 아니다 위에서는 됐다고 하니까 ............... 그럼 솔직히 roscore 잘 동작했고, baudrate은 딱히 조절안해도 잘 동작해왔다. 위에서도 그 쪽은 안 건드리고 한 것 같은데... 실험해볼 것들 1.  rosrun rosserial_server serial_node /dtyACM0 (출처:  https://answers.ros.org/question/164191/rosserial-arduino-cant-connect-arduino-micro/ ) 2.  roslaunch rosserial_server serial.launch port:=/dev/ttyUSB0 3. Leonardo 나 MKR1000, 또는 native USB port를 가진 device들(Arduino UNO, MEGA와 다른)에서 저런 오류가 날 수 있다고 한다. > 얘는 코드 제일 위에  #define  USE_USBCON  을 추가해주면 된다. (출처:  http://wiki.ros.org/rosserial_arduino/Tutorials/Hello%20World  ) 4. delay(1000)을 줘서 sync를 맞췄다는 사람도 있는데, 그럴거였으면 위에서도 안됬어야지 싶기도 하고. 그리고 오히려 delay 때문에 sync가 안 맞는 경우도 있다고.. 5. rosrun rosserial 관련 가능 명령어는 다음과 같다. rosrun rosserial_python serial_node.py _port:=/dev/ttyACM0 _baud:=9600 (다 이거씀 default baud rate는 57600bps) rosrun rosserial_python serial_node.py /dev/ttyUSB0 또는 rosrun rosserial_arduino serial_node.py _port:=/dev/ttyUSB0 (이건 아두이노를 reset 시킨다는데) 그니까 뒤...
자세한 내용 보기

[ROS] 아두이노로 alphabot 알파봇 모터 바퀴 움직이기.

-
이미지
출처:  https://www.waveshare.com/w/upload/c/c7/AlphaBot-User-Manual.pdf alphabot user 메뉴얼에 따르면 alphabot의 모터를 제어할 수 있는 아두이노의 핀은 A0, A1,D5 그리고 A2, A3, D6이다. 이렇게 두 부분으로 나눠서 쓴 이유는 전자가 왼쪽 바퀴 모터를 제어하고 후자가 오른쪽 바퀴 모터를 제어하기 때문이다. 그렇담 왜 바퀴마다 세 개의 핀이 연결되어 있을까? 그 이유는 하나는 forward( 앞으로 가는) 다른 하나는 backward (뒤로 가는) 그리고 나머지 하나는 속도를 제어하는 기능(active high enable 핀)이기 때문이다. 위의 control theory에 따라서 아두이노 코드를 짜면된다. DigitalWrite(A0, HIGH); 이런 식으로! 여기서 신기한게 저 4가지 (IN1, IN2, IN3, IN4) 값을 다 넣어주고 enable 핀 값도 넣어주어야 한다는 사실이다. enable 핀 값은 속도를 넣어주면 된다. 예를 들어 앞으로 가는 (rotate forward) 상황의 아두이노 코드를 짜보면 (아마) 다음과 같다. void moveForward(){ AnalogWrite(D5, 100);   //100의 속도로 왼쪽 바퀴를 돌려라. AnalogWrite(D6, 100);  //100의 속도로 오른쪽 바퀴를 돌려라. DigitalWrite(A0, HIGH); DigitalWrite(A1, LOW); DigitalWrite(A2, LOW); DigitalWrite(A3, HIGH); } 위의 코드는 저 위에 있는 control theory 사진에 나온 논리 값에 따라 적어준 것이다. 왜 저렇게 논리 값을 넣어줘야 바퀴가 도는지가 더 신기하다. 그 이유는 alphabot의 바퀴에 달린 DC모터가 전류가 흘러야 모터가 구동되는 방식이...
자세한 내용 보기