Client Interface 가이드#

Universal Robots의 Client Interface 계열은 외부 소프트웨어가 TCP/IP 기반으로 컨트롤러 통신을 볼 수 있게 해 주는 인터페이스입니다. 이 프로젝트는 그 인터페이스를 작은 파서와 path 기반 상태 모델로 감싸서, GUI나 Python 코드에서 쉽게 쓰게 만든 예제입니다.

이 프로젝트의 interface profile#

Interface preset#
이름	포트	용도	선택 이유
`primary`	`30001`	full primary profile	robot state와 robot message를 함께 보고 싶고 writable primary 채널을 쓰는 환경에 적합합니다.
`secondary`	`30002`	secondary state profile	state 중심으로 보되 primary에서 기대하는 추가 message category에 강하게 의존하지 않는 경우에 적합합니다.
`primary_ro`	`30011`	read-only primary profile	monitoring, diagnostics, service tool처럼 read-only이면서 message도 보고 싶은 경우 가장 좋은 기본값입니다.
`secondary_ro`	`30012`	read-only secondary profile	상태 값 위주로 관찰하는 제품에 적합합니다.
`custom`	사용자 입력	수동 profile	다른 포트를 직접 입력해야 하는 환경에 사용합니다.

패킷 구조를 프로젝트가 어떻게 단순화하는가#

실제 wire format은 바이너리입니다. 보통 size, message type, payload 순으로 이어집니다. 이 프로젝트는 그 구조를 내부에서 파싱하고, 바깥에는 더 다루기 쉬운 모델만 보여 줍니다.

**Robot State**는 robot.mode``나 ``tcp.pose.x 같은 상태 값으로 정리됩니다.
**Robot Message**는 messages 아래 최신값과 히스토리로 정리됩니다.
**Program State Message**는 global variable과 program value 업데이트 구조로 정리됩니다.

즉, 파트너 코드는 대부분 raw byte 대신 value path만 알면 됩니다.

API에서 자주 쓰는 namespace#

robot.*: robot mode, safety mode 같은 상위 상태
tcp.*: Cartesian pose 관련 값
joints.*: joint 이름 기반의 개별 값
globals.* 또는 program.*: global variable과 program state 관련 값
messages.*: 최근 robot message, message history, KeyMessage, 감지된 error text
errors.*: 로컬 DB로 해석된 에러 설명

어떤 profile을 선택할지#

``primary_ro``를 권장하는 경우

read-only 연결이 필요할 때
state와 message를 함께 보고 싶을 때
monitoring, service, diagnostics 도구를 만들 때

``primary``를 선택하는 경우

기존 환경이 writable primary 포트를 쓰고 있을 때
primary 계열 메시지를 그대로 보고 싶은데 포트 정책상 30001을 써야 할 때

``secondary_ro``를 선택하는 경우

state 값 위주 관찰이 목적일 때
read-only 연결을 선호할 때
message 중심 진단이 핵심 요구가 아닐 때

``secondary``를 선택하는 경우

기존 연동이 secondary 기반일 때
state 중심 구성이 자연스러울 때

메시지 종류가 서로 다른 점#

모든 robot message가 동일한 필드를 가지는 것은 아닙니다. 어떤 것은 숫자 code가 있고, 어떤 것은 텍스트 중심입니다. 그래서 이 프로젝트는 한 가지 표현만 고집하지 않고 여러 층을 같이 유지합니다.

파싱된 message record
flatten된 state field
필요할 때 보는 raw packet 진단 정보
recognizable code string이 있을 때의 error lookup 결과

이 방식이 파트너 제품에서 더 현실적입니다. 모든 메시지를 같은 형태로 단정하지 않으면서도, 사용자 화면에는 친절한 정보를 줄 수 있기 때문입니다.