노트북에서 G1의 주소로 ping이 돌아오는데 SDK2 예제가 로봇을 찾지 못하는 장면이 흔하다. ping은 IP 경로 일부가 열린 사실을 보여 줄 뿐, CycloneDDS가 올바른 네트워크 인터페이스에서 참여자를 발견하고 토픽 데이터를 교환한다는 증거는 아니다. ICMP 연결과 DDS 발견·전송을 같은 계층으로 보면 방화벽이나 도메인 문제를 놓친다.
진단은 명령 코드부터 고치지 않고 입력 경로를 따라간다. 물리 링크와 NIC, DDS 도메인·발견, 상태 토픽 수신, 서비스 모드, 마지막으로 제어 명령 순이다. 모터 명령을 시험할 때는 제조사 절차에 맞춰 로봇을 안전하게 지지하고 비상정지 수단을 준비한다. 통신을 고치는 과정이 움직임 안전 검증을 대신하지는 않는다.
진단 입력은 주소보다 인터페이스와 도메인이다
SDK 프로세스가 어느 NIC를 쓰는지 먼저 고정한다. Wi-Fi, VPN, Docker bridge와 유선 어댑터가 함께 있으면 운영체제의 기본 경로와 DDS가 고른 인터페이스가 다를 수 있다. Unitree SDK2 Python 저장소는 예제 실행에서 네트워크 인터페이스를 인수로 지정하는 방식을 보여 준다. 표시 이름을 추측하지 말고 운영체제가 보고한 실제 이름과 IPv4 주소를 기록한다.
- 유선 링크 상태와 G1 쪽 연결 포트, PC NIC의 IPv4 주소·넷마스크를 확인한다.
- Wi-Fi·VPN·가상 어댑터를 포함한 전체 NIC 목록에서 SDK가 사용할 하나를 명시한다.
- 실물과 시뮬레이터가 동시에 켜져 있다면 각 DDS 도메인과 토픽 발행 주체를 적는다.
- 방화벽 변경 전 lowstate 수신 여부와 DDS 발견 로그를 저장해 기준선을 만든다.
- 명령 시험 전 로봇 지지, 주변 통제와 비상정지 절차를 별도로 확인한다.
한 번에 여러 설정을 바꾸면 연결이 살아나도 원인을 알 수 없다. NIC만 바꾸고 상태 수신을 확인한 뒤, 도메인, 멀티캐스트, 방화벽을 차례로 본다. 각 단계에서 명령 송신보다 읽기 전용 상태 토픽을 먼저 사용하면 불필요한 움직임 없이 통신 경로를 확인할 수 있다.
CycloneDDS 설정은 네트워크 지도를 어떻게 표현하는가
CycloneDDS 설정은 사용할 도메인과 네트워크 인터페이스, 멀티캐스트 허용 범위를 런타임에 전달한다. CycloneDDS 공식 설정 참조는 `NetworkInterface`의 이름 선택, `AllowMulticast`와 SPDP 발견 관련 항목을 설명한다. 구성 파일이 존재하는 것만 보지 말고 실행 프로세스가 실제로 그 파일을 읽었는지 환경과 시작 로그를 확인한다.
도메인은 IP 서브넷과 다른 구분자다. 같은 케이블과 서브넷에 있어도 DDS 도메인이 다르면 서로를 같은 통신 공간으로 보지 않을 수 있다. 반대로 시뮬레이터와 실물이 같은 도메인에서 같은 종류의 토픽을 내면 어느 발행자의 상태를 읽는지 혼동할 수 있다. 실물 시험 중에는 불필요한 시뮬레이터 참여자를 끄거나 도메인을 분리한다.
인터페이스 이름을 하드코딩한 설정을 다른 PC에 복사하면 이름이 달라 실패할 수 있다. 이름뿐 아니라 선택된 주소와 서브넷을 시작 로그에 남긴다. 자동 선택을 쓸 때도 여러 NIC가 있는 개발 PC에서는 결과를 검증해야 한다.
ping 다음에는 lowstate가 도착하는지 판정한다
상태 토픽 수신은 연결 진단의 첫 결정점이다. Unitree의 CycloneDDS·UnitreeSDK 공식 위키는 Domain·NIC 초기화와 `lowstate` 수신을 통신 확인에 활용한다. lowstate가 계속 들어오면 적어도 발견과 구독 데이터 경로 일부가 작동한다고 볼 수 있다. 이것이 제어 권한이나 모터 명령 성공까지 증명하는 것은 아니다.
lowstate가 없으면 패킷을 보지 않고 코드만 수정하지 않는다. DDS 참여자 발견이 전혀 없는지, 발견은 되지만 사용자 데이터가 오지 않는지 나눈다. 발견에는 멀티캐스트가 관여하고 실제 데이터는 유니캐스트 경로를 사용할 수 있어 두 단계의 장애 원인이 다를 수 있다. 같은 L2 구간인지, 서브넷이 맞는지, 스위치나 방화벽이 관련 트래픽을 막는지 순서대로 확인한다.
패킷 캡처는 마지막 수단이 아니라 설정과 현실을 맞추는 증거다. 다만 로봇망 전체를 장시간 수집하기보다 시험 PC의 지정 NIC에서 짧은 구간을 기록하고 민감한 주소·데이터는 외부 공유 전에 지운다. 송신만 있고 응답이 없는지, 다른 NIC로 나가는지 확인하면 추측 범위를 크게 줄일 수 있다.
상태가 보여도 명령이 움직임으로 이어지지 않는 경우
상태 수신 뒤에는 서비스 계층과 제어 모드를 본다. SDK2 예제는 고수준 서비스와 저수준 명령이 같은 조건에서 항상 동시에 허용된다고 가정하지 않는다. Unitree 저장소는 저수준 제어 전 `sport_mode` 서비스를 끄는 절차를 명시한다. 이 조치는 네트워크 연결 해결책이 아니라 명령 충돌을 피하기 위한 제어 전제다.
명령이 발행되는 사실과 로봇이 수락하는 사실도 구분한다. 토픽 발행 주기, 메시지 형식, 로봇 상태와 서비스 전환 결과를 함께 남긴다. 처음부터 큰 관절 명령을 보내지 말고 제조사 예제의 안전한 초기화와 제한된 검증 절차를 따른다. Unitree G1 SDK 시작 가이드를 먼저 완료한 환경에서 이 글의 장애 순서를 적용하는 편이 낫다.
서비스 전환이 실패했는데 DDS를 다시 설치하는 식으로 계층을 되돌아가면 시간이 길어진다. lowstate 수신, 요청 응답, 명령 발행, 상태 변화라는 네 관측점을 구분하고 처음 끊기는 지점을 적는다. 그 지점이 다음 조사 대상이다.
피드백이 끊기는 위치를 증거로 맞춰 본다
진단표는 증상보다 마지막으로 확인된 인터페이스를 중심으로 작성한다. ‘연결 안 됨’이라고 쓰면 담당자마다 다른 계층을 고치게 된다. 아래처럼 입력, 발견, 데이터, 서비스와 제어 피드백을 나누면 재현 절차도 짧아진다.
| 확인 지점 | 성공 증거 | 실패 때 먼저 볼 것 | 아직 증명되지 않은 것 |
|---|---|---|---|
| 물리·IP | 지정 NIC의 링크와 같은 서브넷 통신 | 케이블·포트·주소·넷마스크·경로 | DDS 발견과 토픽 수신 |
| DDS 발견 | 의도한 도메인에서 참여자 관측 | Domain·NIC 선택·멀티캐스트·방화벽 | lowstate 사용자 데이터 수신 |
| 상태 구독 | 연속 lowstate와 갱신 시각 | 토픽·QoS·발행 주체·유니캐스트 경로 | 서비스 요청과 제어 권한 |
| 서비스 요청 | 요청에 대응하는 응답과 상태 전환 | 서비스 이름·모드·충돌 프로세스 | 저수준 명령 실행 |
| 제어 피드백 | 제한된 명령 뒤 예상 상태 변화 | 발행 주기·메시지·로봇 상태·안전 조건 | 모든 작업에서의 안정성 |
표의 성공 증거는 다음 단계로 이동할 최소 조건이다. 한 번 수신됐다는 이유로 안정성을 선언하지 않는다. 일정 시간의 갱신 간격, 재시작 뒤 재연결과 케이블 재연결 후 복구도 별도 시험한다.
연결 성공이 제어 안전까지 뜻하지는 않는다
CycloneDDS 설정이 맞아도 스위치 정책, VLAN, 호스트 방화벽이나 컨테이너 네트워크가 현장별로 다를 수 있다. 특정 예제의 도메인 숫자나 인터페이스 값을 보편값처럼 복사하지 않는다. 공식 문서의 예시는 구조를 이해하는 출발점이며 배포망의 보안 정책과 주소 계획이 최종 조건을 정한다.
ping과 lowstate는 각각 제한된 증거다. ping 성공은 DDS 성공이 아니고, lowstate 수신은 제어 명령 수락이나 안전한 보행을 증명하지 않는다. 명령 경로를 확인한 뒤에도 관절 한계, 자세 초기화, 주변 통제와 비상 정지는 별도 절차로 검증한다.
팀이 남길 최종 기록은 ‘설정을 바꿔 해결’이 아니다. 사용한 PC NIC와 주소, 도메인, 구성 파일 해시 또는 버전, 실물·시뮬레이터 실행 상태, 처음 수신된 토픽과 서비스 응답을 남긴다. 그래야 다른 개발 PC에서 같은 오류가 생겼을 때 네트워크와 애플리케이션을 다시 뒤섞지 않는다.
Unitree G1 SDK2 연결 오류 해결 실무 질문
G1 SDK2는 ping이 되면 같은 네트워크 인터페이스를 쓰는 것 아닌가요?
그렇지 않다. ping은 운영체제가 선택한 IP 경로를 확인하지만 CycloneDDS는 설정과 자동 선택 규칙에 따라 다른 NIC를 사용할 수 있다. SDK 실행 시 의도한 인터페이스를 명시하고 DDS 시작 로그와 lowstate 수신으로 확인한다.
명령이 안 먹을 때 가장 먼저 sport_mode부터 꺼야 하나요?
먼저 lowstate가 연속 수신되는지 확인해 통신 계층을 통과해야 한다. 그다음 서비스 요청·응답과 제어 모드를 본다. sport_mode 전환은 저수준 제어의 전제일 수 있지만 NIC·도메인·멀티캐스트 오류를 고치지는 않는다.
자료 마지막 확인: 2026년 8월 26일