Rishabh Garg, Tesla Optimus - Challenges in High Performance Robotics Systems

영상 링크: Rishabh Garg, Tesla Optimus — Challenges in High Performance Robotics Systems
채널명: AI Engineer

테슬라 옵티머스: 고성능 로봇 시스템의 도전과 소프트웨어-하드웨어 통합 문제 핵심 요약

• 본 영상은 테슬라 옵티머스 프로젝트의 Rishabh Garg가 고성능 로봇 시스템 개발에서 발생하는 복잡한 소프트웨어-하드웨어 통합 문제를, 실제 예시와 함께 설명함
• 로봇 시스템에서 “정책 실패”와 “소프트웨어 시스템 결함”이 현상적으로 구분하기 어렵다고 지적하며, 이 둘의 진단·구분 방법을 구체적으로 소개
• 로봇 아키텍처 구축 흐름을 실습용 토이 시스템 예시로 설명: 액추에이터, CPU, 하이브리드 가속기, 센서 등 기본 구조 도식화
• CAN(Controller Area Network) 프로토콜을 활용하는 실제 로봇 통신 설계에서, 데이터 전송량, 전송 시간과 루프 타임이 상호작용해 의도치 않은 지연이 발생하는 구조적 한계 제시
• 메시지 전송/수신 및 정책 실행을 멀티스레딩과 파이프라이닝으로 분리하여, 시스템의 루프 지연 최소화 방안 소개
• 시스템 배포 후 드러나는 액추에이터의 “버벅임” 및 “이상 진동” 현상이 주로 소프트웨어(통신·동기화) 이슈로부터 비롯됨을 상세히 해설
• CAN 버스 외부 트랜시버 및 candump 등 오픈소스 도구를 활용한 메시지 시계열 분석, 문제 진단 프로세스 단계별 설명
• 송신(TX), 수신(RX) 스레드의 비동기화 및 동기화 오류가 메시지 지연 및 명령 스킵 등 실제 기계 거동에 미치는 영향 구체적 사례로 설명
• 로그 처리, 멀티스레드 설계, 우선순위 역전 현상 등 실무에서 무심코 간과하기 쉬운 시스템 레벨의 성능 저하 원인과 대응책을 실사례로 제시
• 끝으로, 파이프라인 구조 설계, 통신 지연 추적, 동기화, 로깅 및 우선순위 조정까지 고성능 로봇 소프트웨어 시스템 설계의 핵심적인 진단·개선 절차를 전체적으로 정리

세부 요약 - 주제별 정리

로봇 시스템의 현상 진단은 정책 문제와 소프트웨어 결함을 구분하는 것이 핵심임

• 로봇 개발 과정에서 ‘정책(policy)이 명령을 내리지 않는가, 아니면 소프트웨어 시스템에 결함이 있는가?‘라는 질문이 매일 반복됨
• 많은 현장에서 로봇의 동작 이상 원인이 외관상 정책 문제처럼 보이나, 실제로는 시스템 소프트웨어 문제에서 기인하는 경우가 다수 발생
• 복잡한 구성요소(센서, 액추에이터, CPU, 가속기 등)와 그 사이 통신이 진단을 어렵게 함
• 정밀 진단의 중요성과, 실제·구체적인 사례 분석의 필요성 강조

CAN 프로토콜의 물리적 한계로 인해 메시지 처리와 루프 사이클에 지연이 누적됨

• CAN(Controller Area Network)은 로봇 통신에서 널리 활용되며, 오픈소스이자 저렴하고 호환성이 뛰어남
• 100비트 짜리 메시지 10개(송신 5개, 수신 5개)와 1Mbps CAN 속도 가정 시, 송수신에 최소 1ms 소요
• 전체 루프(2ms)에 송신/수신이 쏠리면, 실제 정책 실행에 사용 가능한 시간은 줄어듦
• 실측 결과, 1ms 간격의 반복적 ‘갭’이 발생하며 지연을 피할 수 없음이 확인됨
• 설계적으로 수용(accept the delay)하거나, 병렬화·파이프라이닝 등 보완 설계가 필요

멀티스레딩과 파이프라이닝 도입으로 루프 처리 속도를 회복할 수 있음

• 송수신(TX, RX)과 정책(policy) 실행을 각각 별도의 스레드로 분리하여 동시처리 가능하게 재설계
• 첫 수신 데이터로 정책 수행을 시작한 직후, 다음 데이터를 병렬로 받아오고, 이전 정책 결과를 곧바로 송신하는 방식을 도입(파이프라이닝)
• 이 구조에서 RX/TX와 정책 실행이 겹치며, 실질적 루프 타임이 개선됨을 확인
• 스레드·구성 요소가 많아질수록 동기화 문제가 추가로 대두됨

멀티스레드 시스템에서 송신(TX) 동기화 실패는 명령 누락과 지연을 유발함

• 정책(policy) 실행 시간이 불규칙하면, 타이밍을 놓쳐 명령 송신(TX)이 지연되거나 큐에 쌓임
• 그 결과, 다음 루프에서 이전 명령과 이번 명령이 한 번에 연달아 버스에 송신됨: 명령 간 간격 불균형 → 실제 기계에서도 반응 ‘버벅임’ 포착
• TX/RX 스레드간 비동기화도 동일 현상 촉진: 하나의 동기화 오류가 전체 흐름을 깨뜨릴 수 있음
• 동기화(synchronization)를 강화하면 일부 개선되나 완전 해결은 아님

수신(RX) 스레드 비동기화로 정책(policy)의 입력 데이터가 지연되며 기계엔 명령 누락 현상이 발생함

• RX 스레드가 지연될 경우, 정책(policy) 반복(iteration) 시점에 과거 데이터가 입력됨
• 정책 #2에서는 이전 데이터로 동작, #3에서야 최신 명령이 적용되어 실제 출력도 늦어짐
• 모터 등 실제 로봇 부품에서는 ‘단계 건너뛰는 듯한 제어’나 ‘갑작스런 따라잡기(jitter)’ 등 동작 이상이 발생함
• 반복적 동기화 실패는 전체 시스템 성능에 직접적 악영향

시스템 수준 동기화는 저수준 동기화 프리미티브나 데이터 패딩으로 실현할 수 있음

• condition variable, semaphore 등 동기화 프리미티브 활용이 필요(특히 Linux 환경에서 적극 권장)
• 마이크로컨트롤러 등 경량 시스템에서는 동기화 기능이 제한될 수 있으므로, 입력 데이터와 정책 실행 간 패딩(cushion) 추가로 동기화 대체 가능
• 동기화 유지·검증이 소프트웨어 신뢰성 확보의 핵심임을 강조

로그(logging) 시스템의 구현은 성능 저하·정지의 주요 원인이 될 수 있음

• 일반적으로 로그는 무해해 보이나, 과도한 로그 남기기가 루프 타임을 늘리고 시스템을 멈추게 함
• Raspberry Pi와 SD카드에서 주 루프에서 로그-디스크 기록이 이뤄질 경우, 로봇이 30ms 이상 멈추는 현상 실계측
• CPU를 추가로 투입해 로깅을 분리된 서브시스템에서 처리하는 방식으로 성능 저하 문제 해결

마이크로컨트롤러 환경에서는 로그 출력을 통한 체인 리액션으로 전체 패킷 손실이 빈발할 수 있음

• UART 등에서 로그 출력 핸들링이 길어질 경우, 로그-출력이 다음 패킷 수신·처리를 늦춤
• 패킷 드롭 발생 시 로그 메시지를 추가로 남기고, 이 자체가 또 다음 패킷 드롭을 유발 → 패킷 수신 전체 blackout
• 원인 추적이 매우 어렵기 때문에 시스템 설계 시 반드시 사전 고려 필요

우선순위 역전(priority inversion)은 리눅스 커널 등 멀티프로세스 환경에서 시스템 전체를 멈추게 할 수 있음

• 커널이 데이터 인터럽트 처리를 완료해야 유저 프로세스로 데이터가 전달됨
• 모든 프로세스의 우선순위를 지나치게 높일 경우, 오히려 커널 작업 자체가 블록됨
• 이것이 바로 ‘우선순위 역전(priority inversion)’ 현상이며, 실제로 수초 단위 시스템 정지 사례 다수 존재
• 전체 파이프라인별 우선순위 조정과 각 단간 올바른 할당이 필수적

마지막으로, 고성능 로봇 시스템의 설계는 파이프라인 최적화, 통신 병목 해소, 동기화 및 로깅, 우선순위 관리까지 전방위적 진단·개선이 필수임

• 파이프라인 구조를 도입해 cycle time 및 통신 지연을 최소화해야 함
• 동기화 실패 및 통신-정책 스레드간 오류가 예상 외로 미세한 버벅임·진동 등 물리적 현상으로 드러남
• 로그 시스템 및 우선순위 관리 등 사소해 보이는 기능도 전체 성능 저하의 원인이 될 수 있음
• 위 단계별 병목·함정들에 사전 대응함으로써, 실질적인 고성능 로봇 시스템 구축이 가능함을 정리하며 강연을 마무리함