hello, robot

JDAMR은 팔을 달기 전 Cartographer 자율탐사와 지도 저장까지 마쳤고, SO-101에는 손목 카메라 기반 파지 경로가 있어요. 저장 지도를 다시 불러온 localization 주행은 아직 실측 전이고, 현재 차량 자세의 반복 파지 성공도 입증하지 못했어요. 두 기능을 차례로 호출한다고 모바일 매니퓰레이션이 완성되지는 않아요. 주행이 끝났다는 소프트웨어 응답과 차체가 실제로 멈춘 상태는 다르고, 팔이 물체를 들었다는 판정과 운반 가능한 자세도 별개의 증거이기 때문이에요.

현재 세 저장소의 실행 경로와 안전 제한을 대조해 통합 순서를 다시 잡았어요. 이번 범위는 아키텍처와 테스트 명세예요. 새로운 mission coordinator나 권한 노드는 아직 구현하지 않았고 실차 통합 주행도 실행하지 않았어요.

베이스JDAMR · Nav2 Jazzy SO-101 · 손목 RGB 경로 추종Regulated Pure Pursuit 속도 종단Collision Monitor 운용 범위고정 작업대 · 작업자 감독
모바일 기준선
16
검사 묶음 통과
주행 회귀
95
로컬 테스트 통과
대시보드 회귀
26 + 27
단위 · 통합
최근 픽
0 / 4
교시 재확인 필요

구현할 목표 권한 구조(현재 미구현)대시보드관찰 · 시작 · 취소, 물리 권한 없음임무 조정기상태 머신 · 선기록 안전 원장 · 중복 방지양쪽 정지 확인 2개가 모인 뒤 새 권한 버전 발급주행 동작 차단기권한 없음 · 팔 작업 중 · 만료된 권한 = 속도 0속도 0 적용 확인팔 권한 제어기팔 작업 명령 · 팔 실행기 · 손목 카메라정지·자세 유지 적용 확인충돌 감시 → 속도 명령 → 구동기최종 속도 발행자는 하나차체와 팔의 0이 아닌 동작동시 허용 금지

각자 성공한 기능 사이에 닫히지 않은 구간이 있어요

차체 쪽에는 실제 완주 증거가 있어요. Cartographer 자율탐사는 FINISHED와 지도 저장 성공을 남겼고 누적 경로는 45.018미터였어요. 그 과정은 장애물이 멀어도 멈추던 JDAMR 자율탐사를 복구한 네 가지 경계에 기록했어요. 이 기록은 팔을 달기 전 기준선이라 현재 장착 상태의 주행 안전성을 증명한 수치는 아니에요. 현재 Nav2 설정은 Regulated Pure Pursuit를 사용하고 최대 선속도는 초당 0.18미터이며, 속도 완화기 다음에 Collision Monitor가 최종 /cmd_vel을 발행해요.

팔도 이전 뎁스 카메라 구성에서는 물체를 집어 상자에 넣는 사이클을 완주했어요. 과부하 보호 오발이 만든 서보 급사와 뎁스캠 픽앤플레이스 완주에 남긴 결과예요. 지금 차량 구성은 뎁스를 쓰지 않고 손목 RGB 카메라로 바뀌었고, 최근 픽은 4회 모두 실패했어요. 마지막 정렬은 목표에서 105픽셀 벗어났고 케이블이 화면을 가린 상태의 YOLO confidence=0.40 검출은 100프레임 가운데 11프레임에 그쳤어요.

1

통합 코드보다 조작 기본기가 먼저예요

증상주행은 끝나지만 현재 손목 카메라 픽은 반복 성공하지 못해요
원인교시 오차와 케이블 가림이 임무 순서 제어보다 앞선 실패 원인이에요
조치케이블 정리와 재교시 뒤 고정 작업대에서 집기→보유 확인→팔 접기→놓기를 먼저 반복해요 실측 대기

현재 Nav2 도착 판정기는 위치 0.15미터와 자세 0.25라디안 안에 들면 도착으로 판정해요. 반면 SO-101의 손목 탐색 범위와 팬 허용 범위는 더 좁을 수 있어요. Nav2가 성공을 반환해도 물체가 카메라에 없거나 IK가 닿지 않는 위치라면 팔 동작을 시작해서는 안 돼요.

이를 확인하려면 집는 위치와 놓는 위치에서 차체 오차 dx, dy, dyaw를 격자로 바꾸며 표적 고정, IK, 팬 제한이 모두 성립하는 영역을 재야 해요. 이 영역이 capture basin이에요. 실제 Nav2 도착 오차가 이 영역 안에 있을 때만 팔에 권한을 넘기고, 밖이면 팔을 접은 채 차체 정렬을 한 번만 보정한 뒤 다시 판정해요.

2

도착과 조작 가능을 한 판정으로 쓰지 않아요

증상Nav2 성공 뒤에도 손목 카메라의 표적 고정이나 IK가 실패할 수 있어요
원인주행 도착 허용치와 팔이 실제로 닿는 영역을 같은 작업대 좌표에서 대조하지 않았어요
조치도착 오차 분포가 팔이 닿는 영역 안에 있을 때만 팔에 권한을 넘겨요 측정 설계

차체와 팔 사이에 무권한 상태를 두도록 설계했어요

상위 상태 머신에서 owner=ARM이라고 적었다고 두 실행기가 같은 상태가 되는 것은 아니에요. 주행 차단기는 아직 차체 주행 권한의 heartbeat를 받고 팔 실행기는 새 명령을 시작한 짧은 구간이 생길 수 있어요. 그래서 목표 구조에서는 BASE와 ARM 사이의 직접 전환을 없애고, 둘 다 정지한 NONE을 매번 거치도록 정했어요.

전환 계약은 기존 권한 회수, 주행 차단기의 safe_zero ACK, 팔 제어기의 quiescent/hold ACK, 새 epoch 발급, 양쪽 새 권한 ACK 순서예요. 두 응답의 session·epoch·mode가 모두 같기 전에는 Nav2 이동 목표도 팔 Action도 보내지 않도록 했어요. TTL은 수신자의 monotonic clock으로 판정해요. TTL 만료, sequence rollback, session 변경이 생긴 epoch는 폐기하고 늦게 도착한 heartbeat로 되살리지 않아요.

BASE 권한은 관절 자세와 속도 정지, 실행 중인 명령이 없음, payload envelope, 물체를 쥐고 있다는 근거가 최신인지까지 모두 확인된 STOWED_VERIFIED에서만 발급하도록 했어요. 물체 상태가 UNKNOWN이면 주행·그리퍼 개폐·자동 재시도를 금지하고, 임무가 진행 중일 때는 수동·대시보드·기존 방식 명령도 팔 실행기에 쓰기 전에 차단하는 계약이에요.

3

논리 상태와 물리 실행기의 적용 상태를 분리해요

증상조정기의 권한 소유자 값만 바뀌면 두 실행기의 적용 시점이 갈릴 수 있어요
원인한쪽에서만 알리는 권한 대여 방식에는 주행 차단기와 팔 실행기가 같은 전환을 적용했다는 증거가 없어요
조치무권한 상태를 거치는 양쪽 확인 응답과 만료된 권한 버전을 되살리지 않는 잠금 규칙을 계약으로 고정했어요 설계 확정

ROS 2에서는 완료까지 시간이 걸리고 진행 알림·취소가 필요한 작업을 Action으로 모델링해요. 목표 구조에서는 Nav2의 NavigateToPose와 팔의 ExecuteArmSkill을 Action으로 연결해요. 팔 Action 서버, 손목 카메라, 직렬 통신 실행기를 같은 프로세스에 두고 취소 요청이 웹 통신이나 대시보드를 거치지 않은 채 Worker.stop_and_cancel() 경계로 직접 들어가게 해요.

취소는 응답을 기다린 뒤 시작하면 늦어요

팔이 움직이는 중 quiescent ACK부터 기다리면 순환 대기가 생겨요. 팔은 취소 요청을 받아야 멈추고, 조정기는 팔이 멈춰야 ACK를 받는 구조가 되기 때문이에요. 테스트 명세에서는 권한 회수와 Nav2·팔 Action 취소를 동시에 시작하도록 정했어요. 주행 차단기는 속도 0을 출력한 뒤 ACK하고, 팔 제어기는 새 명령을 막고 정지·자세 유지를 수행한 뒤 ACK하도록 정의했어요.

프로세스가 그 사이 죽는 경우도 따로 다뤄야 해요. 설계에서는 명령 의도와 idempotency key를 디스크에 확실히 기록한 뒤 하위 명령을 보내고, 수락된 하위 명령의 식별값과 최종 결과를 차례로 기록하도록 했어요. 기록이 끊긴 임무는 재시작 뒤 자동으로 이어 가지 않고 RECOVER_REQUIRED에서 실제 로봇 상태를 확인하게 해요.

4

취소와 기록 실패를 같은 안전 상태로 모아요

증상ACK 대기나 일부만 기록된 상태에서 재시도하면 같은 물리 명령이 두 번 나갈 수 있어요
원인명령 전송과 기록의 순서를 한 지점으로 확정하는 규칙과 하위 명령의 중복 방지가 없어요
조치권한 회수와 취소를 함께 시작하고, 프로세스 강제 종료 시험에서 중복 물리 명령 0건을 통과 조건으로 뒀어요 검증 명세 완료

손목 RGB만으로 주장할 수 있는 배치 범위를 줄였어요

그리퍼가 열렸다는 readback만으로는 물체가 반납 상자에 들어갔다고 말할 수 없어요. 물체가 죠에 붙었거나, 상자 밖으로 떨어졌거나, 원래 같은 색 물체가 상자 안에 있었을 수 있어요. 손목 RGB 카메라는 깊이가 없어서 임의 작업대의 3차원 배치를 일반적으로 증명하지도 못해요.

첫 구현 범위는 고정 작업대, 단일 식별 물체, 사전에 비어 있는 drop ROI, 고정 fiducial로 묶었어요. 성공은 물체 특징 일치, 상자가 미리 비어 있었음, 같은 물체를 계속 추적했다는 근거, 그리퍼 열림 확인값, drop ROI 안의 물체, 물체가 그리퍼와 함께 움직이지 않는다는 신호가 모두 참일 때만 나와요. 한 관측에서 여섯 신호를 모두 확인하지 못하면 열기·닫기 재명령 없이 한 번 더 관측하고, 그래도 모두 확인되지 않을 때 RECOVER_REQUIRED로 끝내요.

5

보이지 않은 물리 상태를 성공으로 채우지 않아요

증상그리퍼 열기 명령 성공이 실제 배치 성공처럼 기록될 수 있어요
원인물체 놓임, drop ROI 안의 물체, 사전 빈 상태, 동일 물체 연속성이 따로 검증되지 않아요
조치고정 작업 공간의 여섯 신호가 모두 맞을 때만 성공을 허용해요 범위 제한

구현은 정지 작업대에서 시작해요

계획은 0단계부터 6단계까지 일곱 단계이고, 0단계는 0A와 0B 두 관문으로 나눴어요. 이 두 관문이 통과하기 전에는 임무 조정기와 대시보드를 확장하지 않아요.

단계확인할 것다음 단계로 가는 조건
0A케이블·교시·팬 범위·정지 픽앤플레이스10회 중 8회 이상 성공(잠정 예비 기준), 안전 위반·잘못된 성공 0건
0BNav2 도착 오차와 집기·놓기 허용 영역허용 영역 밖 팔 명령 0건
1ExecuteArmSkill과 팔 권한 제어기취소·시간제한·수동 명령 차단 통과
2양쪽 실행기 확인 뒤 권한 전환과 주행 차단기적용 확인 전 하위 명령 0건
3임무 작업 요청과 안전 기록 원장프로세스 강제 종료에서 물리 부작용 중복 0건
4Gazebo 차체 자세와 MuJoCo 팔 자세 결합같은 시드에서 최종 결과 재현
5대시보드 임무 시간선화면이 물리 권한을 갖지 않음
6감독 실차 HIL단계별 원본 증거와 별도 판정

로컬 비접촉 기준선은 통과했지만, 현재 조작 성공률과 팔이 닿는 허용 영역은 아직 실측 관문으로 남아 있어요. 소프트웨어의 최종 결과와 물리 상태 증거가 함께 닫히기 전에는 다음 동작을 시작하지 않는 것이 통합 설계의 기준이에요. 주행과 조작을 더 빨리 잇는 것보다, 어느 쪽도 움직여서는 안 되는 시간을 두 실행기가 같은 epoch로 확인하게 만드는 일이 먼저예요.

공식 계약은 ROS 2의 Topic·Service·Action 구분Nav2 Collision Monitor의 velocity chain 구성을 기준으로 삼았어요. Collision Monitor는 소프트웨어 방어층이며 작업자 감시나 물리 전원 차단을 대신하지 않아요.