21비전 그리핑 · 음성 · 에이전트

보고, 듣고, 알아듣는 로봇팔#

지금까지 reBot 은 우리가 숫자로 알려 준 곳으로만 움직였습니다. "x 0.35 m, y 0, z 0.20 m 로 가라" 같은 식이었지요. 실제 세상에서 쓸모 있는 로봇이 되려면 세 가지가 더 필요합니다.

이렇게 몸을 가지고 실제 세상에서 보고·듣고·움직이는 AI 를 임바디드 AI(Embodied AI, 체화된 AI) 라고 부릅니다. reBot-DevArm 저장소가 첫 줄에 내세우는 목표도 "임바디드 AI 를 배우는 문턱을 낮추는 것"입니다.

이 장은 세 데모를 구조 중심으로 살펴봅니다. 설치 명령은 자주 바뀌므로 핵심만 보이고, 정확한 최신 절차는 각 위키 링크를 따라가세요. 대신 가장 중요한 수학인 "픽셀 + 깊이 → 카메라 좌표 → 로봇 좌표" 변환은 Playground 에서 직접 계산해 봅니다.

비전 그리핑 — 네 단계 파이프라인#

공식 그리핑 데모는 손목에 깊이 카메라(RGB-D) 를 달고, 화면에서 물체를 찾아 집습니다. 지원 카메라는 Orbbec Gemini 2, Intel RealSense D435i, D405 이고 USB 3.0 으로 연결합니다. 손목 거치대 STEP 파일은 저장소의 hardware/camera-mounts/ 에 있고, RS·DM 이 같은 거치대를 씁니다(14장).

1. 인식 — YOLO(You Only Look Once, 한 번에 화면 전체에서 물체를 찾는 신경망)가 물체를 찾아 상자를 그립니다. 공식 데모의 기본 모델은 yoloe-26l-seg.pt 로, 열린 어휘(open vocabulary) 모델이라 "yellow banana", "water bottle" 처럼 찾을 물체 이름을 글로 적어 주면 따로 학습하지 않아도 찾습니다. 가벼운 yoloe-26s-seg.pt, 정해진 종류만 찾는 yolov8n-seg.pt 도 고를 수 있습니다.
2. 깊이 읽기 — 깊이 카메라는 픽셀마다 "카메라에서 거기까지 몇 m" 를 알려 줍니다. 상자 안 깊이 값들의 분위수(예: 가운데 값, depth_quantile 기본 0.5)로 집을 높이를 정합니다. 한 픽셀만 읽으면 잡음에 약하기 때문입니다.
3. 좌표 변환 — 픽셀 (u, v) 와 깊이 d 로 카메라 기준 3D 좌표를 구하고, 이것을 로봇 베이스 기준 좌표로 바꿉니다(다음 절).
4. 집기 — IK 로 닿을 수 있는지 확인한 뒤, 물체 위 접근점(pregrasp_offset_m 0.08 m)으로 가서 → 내려가서(insertion_depth_m 만큼 더 깊이) → 그리퍼를 닫고 → 들어 올려 준비 자세로 돌아옵니다.

그리퍼를 어느 방향으로 벌릴지는 물체를 감싼 최소 넓이 직사각형(OBB, 회전된 상자) 의 짧은 축 으로 정합니다. 바나나처럼 긴 물체는 짧은 쪽을 잡아야 손가락 사이에 들어가니까요.

git clone https://github.com/Seeed-Projects/reBot-DevArm-Grasp.git rebot_grasp
cd rebot_grasp
conda env create -f environment.yml -n rebotarm
conda activate rebotarm
# sdk/reBotArm_control_py 에서 pip install -e .  (SDK 설치)
# RS 는 CAN 을 먼저 올립니다
sudo ip link set can0 type can bitrate 1000000
sudo ip link set can0 up

python scripts/object_detection.py           # ① 카메라·인식만 확인
python scripts/ordinary_grasp_pipeline.py    # ② 팔 없이 그립 추정만 확인
python scripts/collect_handeye_eih.py        # ③ 핸드-아이 보정
python scripts/main.py --dry-run             # ④ 팔을 움직이지 않고 전체 흐름 확인
python scripts/main.py                       # ⑤ 실제 집기 (G 키로 집기)

픽셀 + 깊이 → 카메라 좌표 → 로봇 좌표#

1단계 — 핀홀 공식: 픽셀을 미터로#

카메라는 바늘구멍 사진기처럼 동작한다고 볼 수 있습니다(핀홀 모델). 영상 중심 (cx, cy) 에서 (u − cx) 픽셀 떨어져 보이는 점은, 거리 d 에서 실제로 이만큼 떨어져 있습니다.

xc = (u − cx) · d / fx      ← 카메라 오른쪽 방향 (m)
yc = (v − cy) · d / fy      ← 카메라 아래쪽 방향 (m)
zc = d                      ← 카메라가 바라보는 방향 (m)

닮은 삼각형 원리입니다. 같은 10 픽셀이라도 멀리 있을수록(d 가 클수록) 실제 거리는 더 큽니다. fx, fy(초점 거리, 픽셀 단위)와 cx, cy(영상 중심)는 카메라마다 정해진 내부 파라미터(intrinsics) 입니다. 공식 데모는 이 값을 config/calibration/<카메라>/intrinsics.npz 에 저장합니다.

2단계 — 외부 파라미터: 카메라 좌표를 로봇 좌표로#

카메라 좌표는 "카메라가 본 세상"입니다. 로봇은 베이스 좌표(앞 +X, 왼쪽 +Y, 위 +Z)로 생각하므로 한 번 더 바꿔야 합니다. 카메라가 로봇 어디에, 어느 방향으로 붙어 있는지를 나타내는 회전 R 과 위치 t 를 외부 파라미터(extrinsics) 라고 합니다.

p_base = R · p_cam + t

10장의 변환 행렬과 똑같은 계산입니다. 문제는 R 과 t 를 자로 재서는 정확히 알 수 없다는 것입니다. 그래서 핸드-아이 보정(hand-eye calibration) 을 합니다.

핸드-아이 보정은 어떻게 하나#

공식 데모는 ArUco 마커(검은 테두리의 QR 비슷한 정사각형 표식)를 책상에 두고, 팔을 여러 자세로 옮기며 "그때의 손목 자세(FK)"와 "카메라가 본 마커 자세"를 짝지어 모읍니다. 이 짝들로부터 손목-카메라 사이 변환을 푸는 고전 알고리즘이 TSAI 방법 입니다.

• 자동 모드: python scripts/collect_handeye_eih.py — 미리 정한 50개 자세를 돌며 마커가 안정적으로 보일 때 기록
• 수동 모드: --manual — 중력 보상 상태에서 손으로 팔을 옮기고 Enter 로 기록
• 최소 5개, 15개 이상 권장. 결과는 hand_eye.npz 로 저장
• 마커 한 변 길이(calibration.aruco.marker_length_m, 예시 0.1 m)를 실제 인쇄한 크기와 똑같이 적어야 합니다. 이 값이 틀리면 모든 거리가 같은 비율로 틀어집니다.
• 그래도 몇 mm 씩 어긋나면 calibration.hand_eye_compensation_m 에 X·Y·Z 보정값(m)을 넣어 미세 조정합니다.

실습 — 가상 카메라로 큐브 집기#

실물 카메라가 없어도 변환 수학은 그대로 연습할 수 있습니다. 시뮬레이터의 큐브 위치(arm.cube())를 가짜 카메라가 픽셀로 찍었다고 치고, 우리가 그 픽셀을 다시 로봇 좌표로 되돌려 arm.move_to 로 집으러 갑니다.

import math

# 가상 카메라: 책상 위 0.60 m 에서 똑바로 내려다보는 고정 카메라 (eye-to-hand)
# 영상 위쪽 = 로봇 앞(+X) 이 되도록 달았다고 가정합니다.
FX, FY, CX, CY = 600.0, 600.0, 320.0, 240.0   # 내부 파라미터 (가상의 값)
CAM = (0.30, 0.0, 0.60)                        # 로봇 좌표계에서 카메라 위치 (m)
HALF = 0.02                                    # 깊이는 큐브 '윗면'까지: 윗면 = 중심 + HALF

def robot_to_pixel(p):
    """가짜 카메라: 로봇 좌표 → (u, v, 깊이). 실제로는 YOLO + 깊이 카메라가 주는 값"""
    xc = -(p[1] - CAM[1])
    yc = -(p[0] - CAM[0])
    d = CAM[2] - (p[2] + HALF)
    return round(CX + FX * xc / d), round(CY + FY * yc / d), round(d, 3)

def pixel_to_robot(u, v, d):
    """우리가 만들 함수: (u, v, 깊이) → 로봇 좌표 (큐브 중심)"""
    xc = (u - CX) * d / FX          # ① 핀홀 공식
    yc = (v - CY) * d / FY
    zc = d
    x = CAM[0] - yc                 # ② 외부 파라미터: R = [[0,-1,0],[-1,0,0],[0,0,-1]], t = CAM
    y = CAM[1] - xc
    z = CAM[2] - zc
    return (x, y, z - HALF)         # ③ 윗면 → 중심

cube = arm.cube()
if cube is None:
    print("보기 옵션에서 큐브를 켜 주세요.")
else:
    u, v, d = robot_to_pixel(cube)
    print(f"카메라가 본 것  : 픽셀 ({u}, {v}), 깊이 {d} m")
    x, y, z = pixel_to_robot(u, v, d)
    err = math.dist((x, y, z), cube) * 1000
    print(f"계산한 로봇 좌표: ({x:.3f}, {y:.3f}, {z:.3f}) m  (실제와 {err:.1f} mm 차이)")

    arm.home()
    arm.open()
    arm.move_to(x, y, z + 0.08, t=1.5, down=True)   # 접근점: 8 cm 위
    arm.move_line(x, y, z, t=1.0)                    # 곧게 내려가기
    arm.close()
    arm.wait(0.5)
    arm.move_line(x, y, z + 0.08, t=1.0)             # 들어 올리기

음성 제어 — reSpeaker Flex 와 소리 방향(DoA)#

두 번째 데모는 마이크 배열 reSpeaker Flex XVF3800(마이크 4개가 원형으로 배치, XIAO ESP32S3 와 짝을 이룬 제품)로 reBot B601-DM 을 움직입니다. 두 가지 모드가 있습니다.

DoA 모드 — 소리가 난 쪽으로 돌아보기#

DoA(Direction of Arrival, 도래 방향) 는 소리가 어느 방향에서 왔는지를 각도로 알려 주는 기능입니다. 마이크 4개에 소리가 도착하는 시간 차이로 계산하며, XVF3800 칩이 0~360° 값을 USB 로 컴퓨터에 보내 줍니다. 위키에 소개된 처리 방식은 이렇습니다.

1. 최근 4개 각도를 모아 가중 평균 하고, 튀는 값을 걸러냅니다(잡음·선풍기 소리 대책).
2. 각도가 15° 이상(--threshold) 바뀌면 팔이 그쪽으로 돌아 고개를 끄덕이고, 3초(--cooldown) 동안 쉽니다.
3. 소리가 없으면 "숨 쉬는" 듯한 대기 동작을 합니다.

음성 모드 — 말을 명령으로#

Enter 를 누르고 있는 동안 녹음하고, 놓으면 Whisper(음성→글자)로 받아 적은 뒤 LLM(Llama-3.3-70B, Groq API 경유)이 문장을 다음과 같은 구조화된 JSON 으로 바꿉니다. 답변은 Edge-TTS 로 말해 줍니다.

{"action": "turn_left", "params": {}, "reply": "왼쪽으로 돌게요"}

지원 동작은 왼쪽/오른쪽 돌기, 인사(끄덕이기), 손 흔들기, 영점 복귀, 정지 정도로 단순합니다. 중요한 것은 구조입니다 — LLM 은 팔을 직접 움직이지 않고, 정해진 동작 목록 중 하나를 고를 뿐 입니다.

# 실물용 — 위키 기준. 설치는 위키의 conda/uv 절차를 먼저 따르세요.
python sound_tracking_arm.py --mode doa      # 소리 방향 추적
python sound_tracking_arm.py --mode voice    # 음성 명령

def doa_to_joint1(doa_deg, mic_front=0):
    """마이크 각도 → joint1 각도(도). mic_front = 로봇 정면에 해당하는 마이크 각도"""
    a = (doa_deg - mic_front + 180) % 360 - 180      # -180 ~ +180 로 접기
    if arm.model == 'RS':
        a = -a          # RS 의 joint1 축은 (0,0,-1): 양(+)의 각도가 시계 방향
    lo, hi = arm.limits()['joint1']
    return max(lo, min(hi, a))                       # 관절 한계로 자르기

arm.home()
for doa in [40, 90, 200, 330]:
    j1 = doa_to_joint1(doa)
    print(f"소리 {doa:3d}° → joint1 {j1:6.1f}°")
    arm.move_joint(1, j1, t=1.0)
    arm.move_joint(5, 20, t=0.3)    # 끄덕
    arm.move_joint(5, 0, t=0.3)
    arm.wait(0.5)

임바디드 에이전트 — 말로 시키면 스스로 계획#

세 번째는 wrc_demo 입니다. "빨간 블록 집어 줘" 같은 자연어 명령을 받아 스스로 물체를 찾고, 집는 방법을 계획하고, 안전 검사를 통과한 동작만 실행합니다. B601-RS 와 위쪽에 고정한 RGB-D 카메라를 씁니다.

왜 "반사 → 습관 → LLM" 순서일까#

LLM 은 똑똑하지만 느리고, 가끔 틀리고, 돈(또는 GPU)이 듭니다. "홈으로 가" 같은 명령은 정규식 한 줄로 충분하니 LLM 을 부를 이유가 없습니다. 사람도 뜨거운 것에 닿으면 생각하기 전에 손을 떼고(반사), 매일 하는 일은 습관대로 하고, 처음 겪는 일에서만 곰곰이 생각하지요.

왜 안전 하네스가 따로 있을까#

LLM 이 만든 계획을 그대로 믿지 않기 위해서입니다. 관절 한계에 너무 가까운지, 너무 낮게 내려가지 않는지 같은 규칙은 LLM 이 아니라 평범한 코드가 검사합니다. 위키는 IK 의 한계 여유(limit_margin=0.025)가 하네스의 여유(joint_margin=0.02)보다 반드시 커야 하고 둘을 함께 바꿔야 한다고 강조합니다. IK 가 만든 자세가 하네스에서 걸리지 않도록 한 겹 더 안쪽에서 계획하는 것입니다.

에이전트의 뼈대를 직접 만들어 보기#

LLM 을 쓰지 않아도 구조는 흉내 낼 수 있습니다. 핵심은 세 가지입니다 — ① 명령을 JSON 같은 구조화된 값으로 바꾸기, ② 허용된 스킬 목록에서만 고르기, ③ 실행 전에 안전 검사.

import json

# LLM 이 돌려줬다고 치는 답 (음성 데모의 action/params/reply 형식을 흉내)
llm_answer = '{"action": "pick", "params": {"target": "cube"}, "reply": "큐브를 집을게요"}'

Z_MIN = 0.01        # 이보다 낮게는 내려가지 않음 (하네스 규칙)

def safe_target(x, y, z):
    if z < Z_MIN:
        raise ValueError(f"너무 낮습니다: z={z:.3f}")
    if arm.ik(x, y, z, down=True) is None:
        raise ValueError("IK 해가 없습니다 (닿지 않는 곳)")
    return x, y, z

def skill_pick(target):
    if target != "cube" or arm.cube() is None:
        return "그 물체가 보이지 않아요"
    x, y, z = safe_target(*arm.cube())
    arm.open()
    arm.move_to(x, y, z + 0.08, t=1.5, down=True)
    arm.move_to(x, y, z, t=1.0, down=True)
    arm.close()
    arm.move_to(x, y, z + 0.08, t=1.0, down=True)
    return "집었어요"

def skill_home():
    arm.home()
    return "홈으로 왔어요"

SKILLS = {"pick": skill_pick, "home": skill_home}   # 허용 목록

cmd = json.loads(llm_answer)
print("로봇:", cmd["reply"])
skill = SKILLS.get(cmd["action"])
if skill is None:
    print("모르는 동작이라 실행하지 않습니다:", cmd["action"])
else:
    try:
        print("결과:", skill(**cmd["params"]))
    except ValueError as e:
        print("안전 검사에서 막힘 →", e)

llm_answer 의 "pick" 을 "dance" 로 바꾸거나, Z_MIN 을 0.5 로 올려 보세요. 모르는 명령은 실행하지 않고, 위험한 목표는 막는 것을 확인할 수 있습니다. 진짜 에이전트는 이 llm_answer 자리에 LLM 호출이 들어가고, SKILLS 와 safe_target 이 훨씬 촘촘해질 뿐입니다.

정리#

• 비전 그리핑은 ① YOLO 인식 → ② 깊이 읽기 → ③ 카메라 좌표 → 로봇 좌표 → ④ IK 로 접근·하강·집기·들기 순서입니다. 공식 데모는 열린 어휘 모델 yoloe-26l-seg.pt 와 OBB 짧은 축(그리퍼 방향), 깊이 분위수(높이)를 씁니다.
• 핀홀 공식 xc = (u − cx)·d / fx 가 픽셀을 미터로 바꾸고, p_base = R·p_cam + t 가 카메라 좌표를 로봇 좌표로 바꿉니다. fx, fy, cx, cy 는 내부 파라미터, R, t 는 외부 파라미터입니다.
• 외부 파라미터는 핸드-아이 보정으로 구합니다. 손목 카메라(eye-in-hand)는 현재 FK 를 한 번 더 곱합니다. 공식 데모는 ArUco 마커 + TSAI, 15개 이상 샘플을 권장합니다.
• reSpeaker Flex 는 마이크 4개의 도착 시간 차로 소리 방향(DoA)을 구하고, 음성 모드는 Whisper → LLM → JSON 명령 구조입니다.
• wrc_demo 에이전트는 반사 → 습관 → LLM 의 결정 층, 스킬 런타임, 그리고 모든 경유점을 검사하는 안전 하네스로 이루어집니다. LLM 은 "무엇을" 고르고, "어떻게 안전하게" 는 평범한 코드가 책임집니다.

확인 문제#

1. 깊이 카메라가 영상 중심에서 오른쪽으로 60 픽셀 떨어진 점의 깊이를 0.5 m 로 읽었습니다. fx = 600 일 때 그 점은 카메라 중심선에서 옆으로 몇 cm 떨어져 있나요?
2. 손목 카메라(eye-in-hand)로 본 물체를 로봇 좌표로 바꿀 때, 고정 카메라(eye-to-hand)보다 추가로 필요한 정보는 무엇인가요?
3. 그리퍼가 물체마다 항상 같은 방향으로 약 1.5 cm 빗나갑니다. YOLO 문제와 핸드-아이 보정 문제 중 어느 쪽을 먼저 의심해야 할까요? 그 이유는?
4. 에이전트 구조에서 LLM 이 팔 관절에 직접 각도를 보내지 않고 pick_and_place 같은 정해진 스킬만 호출하게 하는 이유를 두 가지 말해 보세요.