← Docs hub

Booster T2와 SKIX 연동 설계

결론

namuh의 Android 실행 구조를 T2의 Ubuntu 환경으로 옮길 필요는 없다. 두 제품은 각자의 운영체제와 제조사 실행기를 유지하고, 기능 명세·작업 요청·상태·정책 요구·완료 근거만 공통 계약으로 맞추는 구성이 적합하다.

공통으로 맞출 것        Capability · Task · Workflow · State · Evidence · Reason
Android에 남길 것       AAR · Manager · Binder/AIDL · DeviceAgent · Android 제품 기능
T2에 남길 것            Booster Service · Booster SDK · ROS 2/DDS · 모터·센서 안전 제어

Booster SDK는 SKIX를 대체하는 상위 프레임워크가 아니라 T2 기능을 실행하는 공급자다. SKIX는 어떤 기능을 언제 누구에게 맡길지 관리하고, T2는 로봇 내부 동작과 즉시 안전 판단을 소유한다.

SKIX 공용 API를 ROS 2 Topic·Service·Action 자체로 정의하지 않는다. SKIX에는 제조사와 통신 방식에 독립적인 Robot Provider 계약을 두고, ROS 2와 Booster SDK는 그 계약을 구현하는 Adapter로 사용한다. 이 경계가 있어야 Booster가 아닌 로봇을 연결해도 상위 앱·제품 정책·TaskManager 계약을 유지할 수 있다.

상태 표기

• 공개 확인: Booster와 ROS 2의 공개 문서·저장소에서 확인된 기능
• SKIX 기준선: 현재 Android Manager/Binder/DeviceAgent 구조와 TaskManager 설계 기준
• 목표 설계: T2 구매 후 구현·검증해야 하는 교차 플랫폼 연결

1. T2에서 공개된 실행 구조

T2는 31자유도 휴머노이드 플랫폼이며, Education 모델은 ARM 기반 연산 장치, Pro 모델은 NVIDIA Jetson Thor T5000을 사용한다. 카메라·마이크 배열·스피커·IMU가 기본 사양에 포함되고 손 또는 그리퍼는 선택 구성이다.

공개 개발 구조는 세 층으로 읽는 것이 정확하다.

Booster 공식 구조에서는 ROS 2 응용 프로그램은 ROS 2 DDS를 사용하고, 비 ROS 응용 프로그램은 Booster Robotics SDK를 사용한다. 두 경로 모두 로봇의 같은 서비스 계층으로 연결된다. 따라서 모든 기능을 ROS 2 Topic으로 다시 포장하기보다, 의미 단위 기능은 고수준 SDK를 우선하고 고주기 관측만 DDS로 받는 것이 안정적이다.

1.1 운영체제와 ROS 2의 관계

T2를 ROS 기반 운영체제라고 부르면 계층이 섞인다. 공개 문서로 확인되는 구조는 다음과 같다.

즉 운영체제는 Ubuntu/Linux이고, ROS 2는 그 위에서 동작하는 로봇 통신·실행 미들웨어 중 하나다. Booster SDK RPC와 ROS 2/DDS는 같은 제조사 서비스에 접근하는 병렬 경로이며, 어느 한쪽이 다른 쪽 전체를 대체하지 않는다.

1.2 공개 개발 문서가 제공하는 연결 지점

Booster 공개 개발 자료는 하나의 SDK가 아니라 목적이 다른 네 가지 연결 지점을 제공한다.

제품 실행의 기본 경로는 고수준 C++ RPC 또는 Python Task API다. DDS Topic은 연속 상태와 전문가 제어에 사용하고, Agent Framework는 장시간 실행을 직접 붙잡는 계층이 아니라 로봇 내부 앱의 UI·설정·상태 표시 계층으로 사용한다.

공개 범위에서 확인된 기능

공개 자료만으로 확정하면 안 되는 항목

• Python SDK 개요는 T2를 지원 모델로 표시하지만, 일부 공개 저수준 관절 표와 booster_assets는 T1/K1 중심이다.
• T2에는 손 유도 궤적, 자동 축구 동작, 음성 물리 스킬 등 일부 미지원 항목이 별도로 표시돼 있다.
• 실제 구매 형상의 firmware, 31자유도 joint map, URDF, hand/gripper, simulator와 Agent 배포 권한은 계약별로 달라질 수 있다.

따라서 모델명만 보고 Capability를 고정 등록하지 않는다. 부팅 시 모델·firmware·설치 모듈·실제 API 응답을 확인해 해당 기기에서 검증된 기능만 활성화해야 한다.

2. 연동 방식 비교

권장안의 핵심은 코드를 하나로 만드는 것이 아니라 같은 의미와 결과를 공유하는 것이다. Android의 AAR/Binder와 T2의 SDK/ROS 2는 다른 구현이어도 같은 TaskState와 Evidence를 반환할 수 있다.

2.1 범용 ROS 인터페이스를 SKIX에 직접 노출할 것인가

ROS 2의 Topic, Service, Action 구분은 Provider 내부에서 그대로 활용할 가치가 있다. 다만 SKIX Client가 호출하는 것은 mobility.move_to, motion.perform_action, state.observe 같은 제품 의미여야 한다. 실제 Provider는 기능별로 ROS 2 Action, ROS 2 Service, DDS Topic 또는 Booster SDK RPC 중 적합한 경로를 선택한다.

3. 권장 전체 구조

이 그림은 namuhX의 응용 계층·AOSP 표준 API·SKIX 제품 Runtime과 A1·Booster 실행면을 하나의 목표 구조로 연결한다. A1과 Booster는 각자의 기기 정책과 실시간 안전 책임을 유지하고, SKIX에는 제품 의미의 기능·작업·상태·완료 근거만 노출한다.

이 구조에서 A1 리팩터링은 Booster용 직접 의존성을 추가하는 작업이 아니다. 공통 Runtime과 작업 생명주기를 유지하고, Android의 DeviceAgent와 T2의 Booster Service를 각각 독립 Provider로 연결하는 확장이다. 그림의 녹색 상태는 현재 소스에 반영된 공통 Runtime 기준선이고, 주황색 상태의 Provider SPI·공통 schema·구체 Adapter·적합성 시험은 후속 구현 범위다.

3.1 공통 계약 계층

공통 계약은 Protobuf/IDL 또는 동등한 schema 원본에서 Java/Kotlin·C++·Python 타입을 생성하는 방식이 적합하다. AAR은 Android Client 배포 수단으로 유지하되, 교차 플랫폼 계약 자체를 Android Bundle에 묶지 않는다.

3.2 OS별 실행 경계

Android namuh

SKIX Manager AAR → Binder/AIDL → SKIX Runtime/DeviceAgent → Android Domain Executor

Booster T2

SKIX T2 Gateway → Booster SDK RPC / ROS 2 Adapter → Booster Service → Robot Hardware

T2 Gateway는 공급사 API를 공통 Capability로 번역한다. mobility.velocity는 Booster의 속도 명령으로 직접 대응할 수 있지만, mobility.move_to는 이름이 붙은 목적지·자기 위치·경로 계획·도착 판정이 필요하므로 공개 속도 API 하나만으로 구현됐다고 보면 안 된다. 별도의 위치 추정·Navigation Provider가 있을 때만 Capability를 활성화한다. SDK의 진행 상태·odometry·TaskHandle 결과는 공통 TaskEvent로 올린다.

3.3 통신 선택

ROS 2 Topic을 외부 앱에 직접 공개하지 않는다. Topic 이름·QoS·joint layout 변경은 T2 Adapter 안에서 흡수하고, 외부에는 안정된 Capability와 Task 상태만 제공한다.

3.4 Robot Provider 계약

Provider는 ROS 2를 감추기 위한 단순 Wrapper가 아니다. 현재 로봇이 실제로 할 수 있는 기능을 발견하고, SKIX Task를 공급사 실행 요청으로 변환하며, 상태와 완료 근거를 공통 의미로 되돌리는 실행 경계다.

discoverCapabilities()      모델·firmware·설치 모듈 기준 실제 지원 기능 조회
getStateSnapshot()          위치·자세·모드·배터리·안전 상태의 최신본 반환
submitTask(TaskRequest)     공통 Task를 공급사 SDK·ROS 2 요청으로 변환
observeTask(taskId)         진행·보류·완료·실패와 근거를 연속 전달
cancelTask(taskId, reason)  공급자 작업 취소 후 안전한 종료 상태 확인
reconcile(taskId)           연결 복구 뒤 공급자 상태와 SKIX 상태 재조정

다른 제조사를 추가할 때 상위 TaskManager를 수정하는 대신 새 Provider가 이 계약을 구현한다. 모든 로봇이 같은 기능을 가진다고 가정하지 않고, 부팅·연결 시점에 확인된 Capability만 Registry에 등록한다.

3.5 Android/AOSP를 제품 제어면으로 유지하는 이유

Android는 T2의 보행 제어기를 대신하기 위한 선택이 아니다. 사용자·앱·Cloud와 로봇 실행부 사이에서 제품 수명주기와 서비스 경험을 안정적으로 운영하는 제어면으로 가치가 있다.

따라서 권장 구조는 Android 또는 ROS 2의 선택이 아니다. Android/SKIX는 제품 앱·정책·Task·관측을 관리하고, T2의 Ubuntu/Booster Runtime은 로봇 실행과 실시간 안전을 담당한다. 로봇이 바뀌면 Provider를 교체하고, 사용자 경험과 제품 운영 계층은 유지한다.

4. 작업 위임과 완료 판단

여러 기기를 묶는 Workflow와 로봇 내부의 물리 실행은 소유 범위가 다르다. 상위 TaskManager가 전체 순서를 관리하고, T2 Gateway와 제조사 Runtime이 한 단계의 실제 실행을 관리한다.

예시: T2가 거실로 이동해 사람을 향해 안내하고, namuh가 공기질을 확인한 뒤 결과를 화면에 표시

1. 상위 Workflow가 T2 이동, namuh 상태 조회, 안내와 화면 표시의 의존 관계를 만든다.
2. T2 이동 단계는 childTaskId와 함께 T2 Gateway에 위임한다.
3. Gateway는 현재 모드와 SDK 지원 여부를 확인하고 제조사 고수준 API를 호출한다.
4. accepted, running, feedback, succeeded/failed/cancelled를 같은 correlation key로 반환한다.
5. 상위 Workflow는 movement.arrived 근거를 받은 뒤에만 다음 단계를 연다.
6. 연결이 끊기면 성공으로 추정하지 않고 UNKNOWN/RECOVERY_REQUIRED로 보류한 뒤 재조회한다.

ROS 2 Action이 장시간 동작에 Goal·Feedback·Result·Cancel을 제공하고, Booster Python SDK의 TaskHandle이 상태·대기·취소·완료 callback을 제공한다는 점은 이 경계와 잘 맞는다. 다만 두 상태 체계를 그대로 외부에 노출하지 않고 SKIX 상태로 정규화해야 한다.

권장 상태 대응

4.1 SKIX Task의 적정 크기

SKIX TaskManager는 관절이나 모터의 순간 제어를 관리하지 않는다. 외부 호출자가 의미를 이해할 수 있고, 독립적으로 취소할 수 있으며, 시작부터 종료까지 상태와 완료 근거를 추적할 수 있는 행동 단위를 관리한다.

MoveTo(A)처럼 한 문장으로 표현되는 단일 행동도 SKIX Task가 될 수 있다. 중요한 기준은 크기가 아니라 생명주기·취소·자원·완료 근거를 외부에서 관리할 가치가 있는가다. 반대로 보행 중 발목 각도를 조정하거나 매 제어 주기마다 균형을 보정하는 일은 T2 내부 구현이며 SKIX Task로 만들지 않는다.

4.2 센서·단발 이벤트가 발생했을 때

센서 이벤트의 처리 위치는 이벤트 종류가 아니라 영향 범위로 결정한다. 동일한 목표와 완료 조건 안에서 실행 방법만 조정할 수 있으면 T2가 즉시 처리한다. Task 상태나 Workflow 순서가 바뀌면 SKIX가 결정하고, 사용자 목표 자체를 다시 해석해야 하면 상위 Planner 또는 제품 시나리오로 올린다.

T2가 로컬에서 바꿀 수 있는 범위는 Task 계약의 실행 허용 범위 안이다. 예를 들어 A로 이동에서 장애물을 피해 경로를 바꾸는 것은 가능하지만, 장애물이 있다는 이유로 목적지를 B로 바꾸거나 다른 행동을 추가하면 안 된다. 계약 밖의 변경이 필요하면 NEEDS_DECISION과 근거를 올리고 현재 작업을 안전 상태로 보류한다.

4.3 상태 환류 계약

T2가 이벤트를 흡수했더라도 상위에서 알아야 하는 상태는 정규화해 전달한다.

TaskEvent
  task_id / attempt_id / provider_task_id
  state: RUNNING | PAUSED | WAITING | SUCCEEDED | FAILED | CANCELLED | UNKNOWN
  progress
  reason_code / retryable
  observation: source / timestamp / freshness
  evidence: position / mode / safety_state / terminal_result

연속 센서 원본을 모두 SKIX로 올리는 것이 아니라, 상태 판단에 필요한 요약과 근거를 보낸다. 고주기 원본은 T2 내부에서 처리하고, SKIX StateMirror에는 현재 실행을 판단할 수 있는 최신본만 유지한다. 장애 분석이 필요할 때는 correlation key로 T2 원본 로그를 조회한다.

4.4 이 구조의 장점과 비용

가장 큰 위험은 SKIX와 T2가 같은 결정을 동시에 소유하는 것이다. 이를 방지하려면 다음 원칙을 고정한다.

• T2는 즉시 안전과 동일 Task 안의 실행 적응을 소유한다.
• SKIX TaskManager는 Task 생명주기, 자원 충돌, Workflow 순서와 재시도를 소유한다.
• Planner 또는 제품 시나리오는 목표 해석과 Task 구성 변경을 소유한다.
• 로컬에서 처리한 사건도 상위 판단에 영향을 주면 출처·시각·근거와 함께 보고한다.
• 연결 단절 상태에서는 어느 계층도 성공을 추정하지 않는다.

5. 안전·모드·자원 정책

T2는 DAMP, PREP, WALK 등 상태 전이 제약을 가지며, DAMP에서 WALK로 바로 이동할 수 없는 것처럼 제조사 모드 규칙이 있다. SKIX가 이를 우회하면 안 된다.

SKIX 사전 판단       호출자 권한 · 제품 정책 · 작업 충돌 · 사용자 동의
T2 Gateway 판단      capability 지원 · firmware · 현재 모드 · 연결 freshness
T2 최종 판단         로봇 자세 · 균형 · 충돌 회피 · E-stop · 저수준 안전 한계

최종 실행 가능 여부는 세 판단을 모두 통과해야 한다. 상위에서 승인됐다는 이유로 T2의 거부를 성공으로 바꾸지 않으며, T2의 로컬 E-stop과 damping mode는 항상 우선한다.

공유 자원은 최소한 다음 단위로 충돌을 관리한다.

Cloud나 Android에서 joint command를 Wi-Fi로 연속 전송하는 구조는 채택하지 않는다. 제어 주기와 안전 제한이 필요한 loop는 T2 내부에서 닫고, 외부는 목표·제약·취소만 전달한다.

6. Booster 공개 API와 SKIX 연결 범위

Booster Developer Guide의 공개 범위는 넓지만, API가 존재한다는 사실과 T2 납품 형상에서 실행 가능하다는 사실은 구분해야 한다. SKIX는 공개 API를 그대로 복제하지 않고, 제품에서 재사용할 의미 단위만 Capability로 등록한다.

6.1 C++ 고수준 RPC

Move와 MoveCommand는 장소 이름이나 지도 좌표로 이동하는 API가 아니라 속도 명령이다. 반면 C++ MoveController는 odometry를 이용해 MoveToTarget, MoveToRelative, TurnAround, Stop을 제공한다. 이것도 지도·경로 계획·장애물 회피가 포함된 Navigation은 아니므로, mobility.move_to는 별도 Navigation Provider와 도착 근거가 있을 때만 활성화한다.

6.2 Audio API

Player·Recorder·CaptureStream은 서로 다른 세션이다. SKIX에서도 audio.play, audio.record, audio.capture, audio.direction.read로 분리해야 취소·권한·동시 사용 정책과 완료 근거가 명확해진다.

6.3 DDS와 ROS 형식 상태 Topic

ROS 2 기준으로 Topic은 연속 상태, Service는 짧은 조회·설정, Action은 feedback·cancel·result가 필요한 장기 실행에 적합하다. SKIX Client에는 ROS 이름과 QoS를 노출하지 않고 Provider 내부 구현 선택으로 유지한다.

6.4 BoosterOS Python SDK

TaskHandle은 wait, cancel, done, running, 상태 변경 callback과 완료 callback을 제공한다. 공급사 상태를 그대로 노출하지 않고 provider_task_id, attempt_id, TaskEvent, terminal evidence로 정규화한다. DataNotReadyError는 값이 0이라는 뜻이 아니라 현재 채널에서 상태가 준비되지 않았다는 뜻이므로, 과거 값을 현재 상태로 대체하지 않는다.

6.5 Booster Agent와 공개 개발 자원

Agent callback은 기본적으로 직렬 실행되므로 긴 작업을 callback 안에서 기다리면 안 된다. callback은 요청 접수와 상태 갱신만 수행하고, 장기 작업은 별도 worker나 SKIX/T2 Task 경로로 넘겨야 한다.

6.6 초기 Capability 등록안

Capability에는 provider, model, firmwareRange, resources, preconditions, cancelContract, evidenceContract를 둔다. 런타임에서 확인되지 않은 기능은 Planner와 앱의 선택 후보에 노출하지 않는다. 관절 직접 제어, 무제한 속도 스트림, calibration은 기본 Client API가 아니라 서명된 진단·전문가 권한으로 분리한다.

초기 연결 순서는 상태 조회 → Audio·LED·머리 자세 → 목록 기반 사전 동작 → 제한 이동 → Vision → 별도 Navigation이 적합하다. 손·관절·학습 궤적은 실제 T2 형상과 안전 시험이 끝난 뒤 별도 등급으로 연다.

7. 도입 단계와 통과 기준

1단계 · 구매 형상 확인

• T2 Education/Pro, hand/gripper, firmware와 개발 계정 권한을 확정한다.
• SDK·ROS 2·Agent·simulator의 T2 지원표와 31자유도 joint/URDF 자료를 공급사에 확인한다.
• E-stop, mode 전환, OTA, 로그 접근과 앱 서명·배포 조건을 확인한다.

통과 기준: 실제 납품 형상과 문서의 기능표가 일치하고, 미지원 기능이 명시돼 있다.

2단계 · 읽기 전용 Adapter

• model, firmware, mode, battery, IMU, odometry와 active task를 StateSnapshot으로 변환한다.
• 각 값에 source, timestamp, freshness를 붙인다.
• 재부팅·네트워크 단절 뒤 과거 값을 현재 상태로 재사용하지 않는다.

통과 기준: 실기기와 simulator에서 상태 schema가 같고 stale 값이 차단된다.

3단계 · 안전한 단일 작업

• 자세 조회, audio, 정해진 action처럼 위험이 낮은 고수준 기능부터 연결한다.
• accepted·progress·cancel·terminal reason을 공통 TaskEvent로 변환한다.

통과 기준: 요청 ID 하나로 시작부터 terminal evidence까지 추적할 수 있다.

4단계 · 이동과 Workflow

• 이동·정지·취소·timeout을 연결하고 mode·resource admission을 적용한다.
• 상위 Workflow와 T2 Child Task의 재연결·중복 요청·취소 경쟁을 시험한다.

통과 기준: 단계 성공을 추정하지 않고 실제 근거 뒤에만 다음 단계가 열린다.

5단계 · 제품 시나리오

• namuh와 T2의 역할을 나눈 시나리오를 구성한다.
• 같은 요청을 simulator, 단일 T2, namuh+T2 환경에서 재생하고 계약 호환성을 검증한다.

통과 기준: 공급자 구현이 달라도 상위 Workflow와 관측 화면이 같은 상태 체계를 사용한다.

8. 공급사 확인 목록

9. 현재 판단과 남은 검증

Connections

• 부스터로보틱스 SDK 검토 자료 — SDK 구성·API·개발 환경과 지원 제약

• SKIX 리팩터링 프레임워크 설계안

• Resource·Capability·Task Runtime 상세 구조
• Request-to-Evidence 전체 흐름
• TaskManager 전체 사양

Sources

• Booster Developer Guide
• Booster T2 Overview
• Booster T2 Specifications
• Booster T2 Modes
• Booster Robotics SDK Architecture
• Booster Robotics SDK RPC Interfaces
• Booster Motion-Control Interfaces
• Booster C++ Controller Wrappers
• Booster C++ API Reference
• Booster Device Information Interfaces
• Booster AI and LUI Interfaces
• Booster Vision Interfaces
• Booster Camera Interfaces
• Booster Lighting Interfaces
• Booster Audio Module
• Booster Robotics SDK Low-Level Topics
• BoosterOS Python SDK Overview
• BoosterOS Python TaskHandle
• Booster Robot Development Protocol
• ROS 2 Interfaces: Topics, Services, Actions
• ROS 2 Actions
• AOSP Architecture Overview
• AOSP Binder Overview
• Android Application Sandbox
• AOSP A/B System Updates
• Booster Agent Overview
• Booster Agent API Overview
• Booster Robotics SDK ROS 2
• Booster Robotics SDK
• ROS 2 Managed Nodes