2009. 12. 6. 16:10
NOVA Project(Hovering Robot)
※ 이 포스트의 도표 및 테이블은 U-Blox사의 Protocol Specifications을 참조하였습니다.
UBX Protocol
UBX Protocol은 U-Blox사에서 자체적으로 만든 프로토콜로써 NMEA-0183규격과 다르게 GPS로 수신한 데이터를 Binary Data Type으로 전송합니다. U-Bolx사의 GPS모듈은 이전 포스트에서도 설명했듯이 NMEA과 UBX프로토콜의 동시출력이 가능합니다. U-Blox사에서 제공하는 U-Center프로그램을 사용하여 NMEA Protocol, UBX Protocol의 출력 선택을 할 수가 있는 것입니다. 저같은 경우에는 NMEA방식이 아닌 UBX Protocol을 사용하여 GPS Auto Pilot Controller에 적용을 시킬 계획입니다.
NMEA Protocol보다 UBX Protocol을 사용하면서 편리했던 점이 처리하는 속도에서 보다 더 큰 효율을 낼 수 있는 것 같았습니다. NMEA Protocol의 경우 ASCII방식으로 들어오기 때문에 별도의 Buffer가 필요하며 ASC를 Buffer에 저장시킨 후 Character 형태의 Data를 Integer또는 float형태의 데이터로 변환해 주는 과정을 거쳐야만 합니다. 반명 UBX프로토콜의 경우 Binary(HEX) value로 data가 들어오기 때문에 앞부분의 sync byte. Class 그리고 ID값이 확인되면 데이터를 바로 읽어들여 변수로 저장하기 때문에 별도의 변환과정이 필요 없어 이점에서 편리한 것 같습니다. 덕분에 Parsing도 보다 수월하게 됩니다. 또한 NMEA와는 다르게 CRC가 존재하기 때문에 데이터에대한 신뢰도가 보다 더 높은 것 같습니다.
기본적인 UBX Protocol은 다음과 같습니다.
NMEA Protocol보다 UBX Protocol을 사용하면서 편리했던 점이 처리하는 속도에서 보다 더 큰 효율을 낼 수 있는 것 같았습니다. NMEA Protocol의 경우 ASCII방식으로 들어오기 때문에 별도의 Buffer가 필요하며 ASC를 Buffer에 저장시킨 후 Character 형태의 Data를 Integer또는 float형태의 데이터로 변환해 주는 과정을 거쳐야만 합니다. 반명 UBX프로토콜의 경우 Binary(HEX) value로 data가 들어오기 때문에 앞부분의 sync byte. Class 그리고 ID값이 확인되면 데이터를 바로 읽어들여 변수로 저장하기 때문에 별도의 변환과정이 필요 없어 이점에서 편리한 것 같습니다. 덕분에 Parsing도 보다 수월하게 됩니다. 또한 NMEA와는 다르게 CRC가 존재하기 때문에 데이터에대한 신뢰도가 보다 더 높은 것 같습니다.
기본적인 UBX Protocol은 다음과 같습니다.
UBX Protocol은 모든 메세지가 시작할 때 앞부분에 0xB5 0x62의 메세지를 가지고 있습니다. 이는 UBX Packet Message가 시작됨을 알리는 sync byte입니다. 그리고 바로 이어서 따라오는 Byte는 Class와 ID를 나타내고 있습니다. 그 다음 2Byte에는 Packet의 Payload Length정보를 갖고 있습니다. 이를 사용해서 Parsing함수에서 데이터의 길이대로 데이터를 읽어올 수 있습니다. 이 길이는 해당 메세지에 따라서 Length가 정해져 있습니다.
마지막으로 2 Byte에는 해당 Packet의 Checksum이 위치하고 있습니다. 이 Checksum을 사용하여 해당 Packet이 정확한지 체크가 가능합니다.
마지막으로 2 Byte에는 해당 Packet의 Checksum이 위치하고 있습니다. 이 Checksum을 사용하여 해당 Packet이 정확한지 체크가 가능합니다.
ㆍUBX Class IDs
위 표를 보시면 Class별로 해당하는 정보와 Class값을 확인 하실 수 있습니다. 간략히 설명하자면 NAV Class는 Navigation에 필요한 Position, speed, Time, Acceleration, Heading, DOP(Dilution Of Precision)등을 아실 수 있습니다. SVs used는 측정에 사용되는 GPS의 갯수입니다.(이것은 제 개인적인 사견입니다..;; 잡히는 위성의 갯수는 보통 17~18개정도로 평균 잡히지만 수신률이 좋은 위성만 측정에 사용이 되는 것 같습니다. 이 수신 감도가 좋은 위성의 갯수를 SVs Used값으로 나태내 주는 것 같습니다)
RXM은 위성의 수신상태를 알려주는 Class입니다.
INF같은 경우에는 GPS의 Message Print Type, Notice등 GPS 기본설정에 관련된 Information을 나타내 줍니다.
ACK는 CFG Message에 대해서 ACK or NACK를 알려주는 메세지를 보내줍니다.
RXM은 위성의 수신상태를 알려주는 Class입니다.
INF같은 경우에는 GPS의 Message Print Type, Notice등 GPS 기본설정에 관련된 Information을 나타내 줍니다.
ACK는 CFG Message에 대해서 ACK or NACK를 알려주는 메세지를 보내줍니다.
MON은 GPS안에 있는 CPU Load, Stack의 Usage등 시스템 정보를 보여주는 메세지입니다.
이밖에 Ephemeris(천체력), Almanac(달력)등을 표시해주는 AID Class 그리고 Timining Message를 출력해주는 TIM Class가 있습니다.
이밖에 Ephemeris(천체력), Almanac(달력)등을 표시해주는 AID Class 그리고 Timining Message를 출력해주는 TIM Class가 있습니다.
ㆍUBX Checksum
UBX Protocol의 Checksum에대해 간략히 설명드리자면 Sync character와 Checksum을 제외한 나머지 부분을 계산합니다. TCP standard(RFC_1445)를 따르고 있습니다.
ㆍUBX Protocol - NAV-POSLLH Message
저같은 경우에는 UBX Protocol Message중에서 NAV Class의 POSLLH, SOL 그리고 VELNED Message를 읽어들여 GPS데이터를 사용했습니다. 이하부터는 이 세개의 메세지를 기준으로 설명을 드리고자 합니다.
우선 처음으로 설명 드리고자 하는 Message는 POSLLH입니다. 이 MEssage는 Geodetic Position Soulution정보를 나태내줍니다. 즉, GPS의 시간, 현재 위치한 Latitude와 Longitude그리고 ellipsoid(타원) 위에서의 높이와 해수면을 기준으로 한 높이가 나타납니다. 또한 Horizontal & Vertical Accuracy값을 나타내 줍니다.
NAV-POSLLH의 메세지는 다음과 같은 구조로 나타납니다.
NAV Class라는 것을 ID를 통해서 알 수 있고 0x02는 POSLLH Message라는 정보를 나타내 줍니다. 데이터를 분리해 낼 경우에 Length값이 고정되어있기 때문에 다른 값이 들어오는 경우 제외를 시키도록 별도 처리를 해주어야 합니다. 필자의 경우 GPS데이터를 수신하는 경우에 간혹 데이터가 파싱이 될때 데이터값으로 한참 읽고있는 경우를 겪었는데 알고보니 Checksum을 하기전에 데이터의 길이만큼 데이터(payload)를 읽어오면서 발생하는 문제 였었습니다. 이런 경우는 간혹 일어나는데 error나는 부분이 Length에서 일어나게되면 최악의 경우 0이 되어버리면 거의 무한루프에 빠진 것처럼 돌게 됩니다. 이 부분은 프로그래밍을 하시는 분들이 각별히 유의하셔서 신경써 주셔야 할 부분입니다.
다음 화면은 U-Center를 사용해 POSLLH메세지를 받은 화면입니다.
위 화면을 보시면 아래쪽에 패킷의 데이터를 볼 수 있으며 U-Center에서 자동으로 데이터를 읽어들여 단위별로 표시됨을 알 수 있습니다.
여기서 주의해야 할 점은 Longitude와 Latitude의 단위입니다. MNEA방식에서는 ddmm.mmmm, dddmm.mmmm방식으로 출력이 되지만 UBX Protocol방식에서는 ddd.ddddddd, dd.ddddddd방식으로 출력이 됩니다. 저는 이 부분을 놓쳐서 아무리 좌표를 도분초단위로 바꾸어도 다른 좌표로 나오는 문제가 발생하여 한참 고민을 했었습니다.
아래 화면은 제가 GPS에서 수신한 데이터를 받아서 파싱후 각 변수에 저장 후 그 값을 Serial Port로 출력한 내용을 저장한 것입니다.
| - Longitute : 127.0251886 Degrees ☞ 127 Degrees 1.511316 Minutes ☞ 127 Degrees 1 Minutes 30.67896 Seconds |
- Ltitute : 37.4938136 Degrees ☞ 37 Degrees 29.628816 Minutes ☞ 37 Degrees 29 Minutes 37.72896 Seconds |
각 소수점 자리들을 분과 초로 바꾸어 주기 위하여 60을 곱하면 됩니다.
위 좌표를 토대로 Google Earth를 통하여 검색을 해보면 다음과 같이 해당 좌표가 나오겠지요??
ㆍUBX Protocol - NAV-SOL Message
다음으로 설명드릴 것은 SOL Message입니다. 이 메세지는 네비게이션에 관련된 정보들을 출력해 줍니다. 출력되는 Message의 구조는 다음과 같습니다. 이 메세지는 호출의 의해서 메세지를 받을 수도 있고 주기적으로 송신하도록 할 수도 있습니다.
SOL Message에는 위성의 수 그리고 Position Fix type, 그리고 x,y,z 각 축에 대한 Velocity(Speed)가 m/s단위로 측정이 되며 현재 위치한 Position의 값을 나타내 줍니다. 이를 활용하여 Navigation에 사용이 가능합니다.
ㆍUBX Protocol - NAV-VELNED Message
VELNED Message는 속도에 관련된 데이터를 전달해 줍니다. SOL Message에서는 각 축에대한 속도를 표시해 주었지만 VELNED는 평면과 3D에대한 속도값을 보여줍니다. 또한 이동하는 방향 그리고 동서남북 방향에대한 속도값 출력을 해줍니다.
메세지 타입은 다음과 같습니다.
위 화면에서도 알 수 있다시피 메세지를 통해서 속도 값을 알 수 있습니다.
이밖에도 많은 메세지들이 있으며 첨부한 U-Blox사의 Protocol Specifications PDF파일에서 확인 하실 수 있습니다.
u-blox5_Protocol_Specifications.pdf U-Blox사의 Protocol을 사용하면서 느낀점이 참 편리하다라는 것이었습니다. NMEA방식의 프로토콜을 사용하는 것보다 데이터를 사용하기가 보다 더 편리하며 CRC의 존재, 그리고 칩셋 제조회사에서 제공하는 관리프로그램의 제공으로 다른 GPS보다 더 사용하기가 편리한 것 같습니다. 또한 GPS firmware의 업데이트가 U-center를 통해서 가능하다는 것이 큰 매력인 것 같습니다.
가격은 비싸더라도 비싼 값을 하는 것 같네요^^
가격은 비싸더라도 비싼 값을 하는 것 같네요^^
'NOVA Project(Hovering Robot)' 카테고리의 다른 글
| Nova 2호기 처녀비행!! (0) | 2009.12.10 |
|---|---|
| Nova 1호 처녀비행! (0) | 2009.12.08 |
| Eddy Embedded Module Conference 참가 후기 (0) | 2009.12.06 |
| NMEA & UBX Protocol(1) (0) | 2009.12.02 |
| Nova Auto Flight Controller Prototype based on GPS (3) | 2009.12.02 |
