...
POST No. 2591646
Bulk Read - Status Packet 관련
2021-08-24 15:46:04 ekfrnak

DYNAMIXEL Protocol 1.0 e-Manual 내용의 Bulk Read - Status Packet에 대하여 문의 드립니다. 

메뉴얼의 내용과 같이 두 개의 ID로부터 수신한 Status Packet 처리시 첫 번째 ID의 Checksum 코드가 0xFF가 된다면,

연결된 두 ID의 패킷을 정상적으로 분리하여 처리할 수 없을 것으로 보입니다.

 > 0xFF 0xFF 0x01 0x04 0x00 0x00 0x80 0x7A 0xFF 0xFF 0x02 0x04 0x00 0x00 0x80 0x79 

 > 적색의 "0x7A" "0xFF" 된다면! 어떻게 두 ID의 패킷을 분리할 수 있는가?

첫 번째 ID 패킷 종료 시점과 두 번째 ID 패킷 시작 시점 사이에도 "Return Delay Time" 파라메터가 적용되는지

궁금합니다.


감사합니다.

2021-08-24 15:46:04
ekfrnak
2021-08-24 17:51:32 유기웅

안녕하세요.

 

Instruction PacketLength값에 따라 정해집니다.

 

0x7A가 0xFF여도 두 ID의 패킷은 분리가 됩니다.

 

0xFF 0xFF 0x01 0x04 (0x00 0x00 0x80 0xFF) 0xFF 0xFF 0x02 0x04 (0x00 0x00 0x80 0x79) 

 

감사합니다.

comment
2021-08-24 18:09:20 ekfrnak
안녕하세요?

"Length" 필드의 값은 "Checksum" 필드의 값이 검증 되어야 참조가 가능하지 않습니까?

감사합니다.
2021-08-24 18:09:20
ekfrnak
2021-08-25 09:18:12 ykw4463
Checksum 은 Packet이 통신 중에 파손되었는지를 점검하기 위해 사용됩니다. 아래와 같은 방법으로 Checksum을 계산할 수 있습니다.
Checksum = ~( ID + Length + Instruction + Parameter1 + … Parameter N )

프로토콜1.0 Checksum 내용입니다. 참고해주세요.
https://emanual.robotis.com/docs/kr/dxl/protocol1/#checksum-instruction-packet
2021-08-25 09:18:12
ykw4463
2021-08-25 10:22:29 ekfrnak
댓글/답변이 의도하지 않는 방향으로 달려서 다시 정리를 하겠습니다.
■ 질문의 출발점
: 두 개의 ID로부터 Bulk Read-Status Packet을 수신시 패킷을 처리하는데 문제가 있을 수 있음!
- 수신된 상기의 패킷을 처리하는 일반적인 절차는...
> 제일먼저 두 ID로부터 수신된 패킷을 분리
>> 분리하는 기준은 헤더(0xFFFF)값을 기준으로 두 ID의 패킷을 분리한다.
※ 첫 번째 ID로부터 수신한 패킷의 Checksum 값이 0xFF가 된다면, 헤더 값을 기준으로
분리하면 한 바이트가 모자른 불완전한 패킷이됨.
※ 현 시점에서는 Checksum값이 검증되지 않았기 때문에 "Length" 필드값을 사용 불가.
> 두 번째는 분리된 패킷의 맨마지막 바이트인 Checksum값을 계산방법을 통해 검증
>> Checksum값 검증에 문제가 없으면, 세 번째 단계 진행.
> 세 번째는 패킷 구조에 맞게 상태 및 수신데이터를 처리
※ 이 시점에서야 "Length" 필드의 값을 참조/사용 가능.

■ 해결하고자 하는 방법의 의도
: 첫 번째 ID 패킷 종료 시점과 두 번째 ID 패킷 시작 시점 사이에도 "Return Delay Time"
파라메터가 적용된다면, 이 공백시간을 기준으로 패킷을 분리하고자 함.
2021-08-25 10:22:29
ekfrnak
2021-08-25 11:57:15 ykw4463
>> 분리하는 기준은 헤더(0xFFFF)값을 기준으로 두 ID의 패킷을 분리한다.
분리하는 기준을 0xFFFF값을 기준으로 분리를 하시면 안됩니다.
Length 크기에 따라 분리가 됩니다.
2021-08-25 11:57:15
ykw4463
2021-08-25 19:28:28 ekfrnak
수신된 "Length" 필드는 Checksum 계산시 포함이 되기 때문에 Checksum 코드 검증이 완료된 후에나 참조/사용이 가능한거 아닌가요? Checksum 코드 검증 전에 4번째 필드가 "Length" 이니까 그 값을 참조하여 잔여 데이터를 읽어 패킷을 분리/처리하는 것이 정상적인 절차 맞습니까? "Length" 필드의 값이 전송과정에서 손상되었다면 그 값이 최대 0xFF가 될 수도 있는데...
2021-08-25 19:28:28
ekfrnak
2021-08-24 17:51:32
ykw4463
2021-08-25 14:01:13 최대성

제 생각에는, 패킷을 수신하는 시점부터 생각을 해봐야 할 것 같습니다.

패킷을 수신하고 검사하는 방법을 순서대로 적어보면 다음과 같기 때문에, 말씀하신 경우는 자연스럽게 해결이 됩니다.

쓰레기 데이터 없이, 정상적인 데이터만 유입될 경우에는 해독하는데 큰 문제가 없습니다.

 

1) 먼저 (0xFF 0xFF)를 찾고

2) 4번째 바이트(Length)를 받은 후 앞으로 몇바이트를 더 받아야 하는지 확인

3) Length에 의해 패킷이 완성되었다면, Checksum으로 패킷 검사.

 

문제는 통신환경에 노이즈가 많을 경우, 종종 쓰레기 데이터가 유입되면서 발생합니다. 

쓰레기 데이터는 대체로 패킷을 송수신할 때는 발생되지 않고, 대기상태일 때 발생합니다.

마침 쓰레기가 0xFF 로 발생한다면, 패킷을 어떻게 판단할지에 대한 고민이 생길수는 있습니다.

 

가장 대표적인 방법은 타임아웃입니다. 일정시간 패킷이 완성되지 않으면 버립니다. 

타임아웃과 헤더의 형태로 꽤 많은 쓰레기는 버릴 수 있습니다.

가장 큰 문제는 (0xFF 0xFF 0xFF ID Length ..... Checksum)과 같이 들어올 때 입니다. 

이경우에는 패킷 판별을 어떻게 구현하느냐에 따라 달라질 수 있을 것 같습니다.

 

프로토콜 2.0은 이러한 패킷의 검사방법을 강화하기 위해서 만든게 아닐까 싶습니다.

헤더가 더 복잡하게 (0xFF 0xFF 0xFD 0x00) 이렇게 구성되어 있더군요.

바이트 스터핑이란 구조도 있어서 해더를 찾는 부분이 많이 개선된듯 합니다.

패킷 검사 부분도 CRC를 도입해서 강화한것 같습니다.

제 경우에는 프로토콜 1.0 사용할 때, Checksum이 뚫리는 경우도 있었습니다. 

 

2021-08-25 14:01:13
gaiajoypop@gmail.com
답변달기
웹에디터 시작 웹 에디터 끝