두 대가 참여했는데,
왜 한 대만 전환됐을까?

01 / Problem

로봇을 추가하는 것만으로는 부족했습니다.

독립된 제어기를 사용하는 Indy12 두 대를 하나의 세션에서 지원해야 했습니다. 기존 플랫폼에는 로봇을 여러 대 등록할 수 있는 부분이 있었지만, 실제 수집과 조작은 화면에서 선택한 한 대를 중심으로 동작했습니다.

두 대를 연결한 뒤 Collect에서 텔레오퍼레이션 모드로 전환했을 때, 선택된 로봇만 전환됐습니다. 저는 장비 연결보다 기존 기능이 무엇을 작업 대상으로 보고 있는지부터 확인했습니다.

02 / Investigation

처음 고친 곳만으로는 문제가 끝나지 않았습니다.

1. 전환 요청의 대상을 확인

   Collect의 텔레오퍼레이션 진입 요청이 화면에서 선택된 로봇을 따라가고 있었습니다. 먼저 세션 전체를 대상으로 요청하도록 바꿨습니다.

2. 반대 방향의 동작도 다시 확인

   진입 요청을 바꾼 뒤에도 idle 복귀에서는 화면의 단일 로봇 상태로 대상을 추정하고 있었습니다. Stop 역시 수집기의 단일 로봇 정보만 읽었습니다.

3. 공통 가정을 찾아 수정 범위를 넓힘

   각 버튼을 따로 고치는 대신, “현재 화면 선택이 전체 작업을 대표한다”는 가정을 바꿔야 한다고 판단했습니다. 화면 선택과 실제 세션 참가 목록을 분리했습니다.

03 / Architecture

화면의 한 대와 작업의 두 대를 나눴습니다.

세션 참가 목록과 순서를 기준으로 대상을 정하고, 수집 모드 전환과 정지 요청에서 같은 기준을 사용하도록 수정했습니다. 전환 도중 한 로봇이 실패하면 이미 전환된 로봇을 idle로 되돌리는 처리도 넣었습니다.

데이터에서도 비슷한 문제가 있었습니다. 저장 파일에는 두 손의 값이 있었지만 수집 계획과 일부 메타데이터는 선택된 한 로봇의 손만 설명했습니다. 참가 로봇 전체의 장치 목록으로 계획을 만들고, 로봇별 식별자와 순서를 수집·학습 산출물·추론 출력까지 유지하도록 처리했습니다.

같은 크기의 배열도, 로봇 소속은 끝까지 유지

04 / Validation

화면에서 보인 결과를 파일과 실제 동작까지 확인했습니다.

1. 선택을 바꿔도 참가자는 유지되는가

   화면의 로봇을 바꿔도 수집 대상 두 대가 유지되는지, 세션 전체의 조작·정지 요청이 연결되는지 확인했습니다.

2. 같은 로봇을 가리키는가

   수집 파일·계획·메타데이터의 로봇과 장치 목록을 대조하고, 학습 입력과 추론 출력의 소속·순서를 구분해 검사했습니다.

3. 기존 기능도 계속 동작하는가

   기존 단일 로봇 데이터와 양팔 데이터의 해석 경로를 유지하고, 새 경로가 기존 의미를 덮어쓰지 않는지 확인했습니다.

독립 제어기 기반 로봇 두 대에서 모드 전환·정지와 데이터 소속·순서, 학습 입력과 추론 출력의 연결을 확인했습니다. 이 과정에서 참가 목록과 로봇별 메타데이터를 공통 기준으로 사용해, 이후 N대 확장에도 적용할 처리 구조를 정리했습니다.

05 / Takeaway

로봇 대수의 확장에서, 협업 범위의 확장까지