제9부 매니퓰레이션

9.6 매니퓰레이터 배치 실무

9.6.1 이 장에서 배우는 것 / 선수 지식

데모가 되는 것과 제품이 되는 것 사이에는 큰 거리가 있다. 데모는 조건이 갖춰진 상태에서 한 번 성공하면 되지만, 제품은 하루 수천 번을 몇 년간 반복해야 한다.

이 장은 그 거리를 다룬다. 작업 공간을 어떻게 배치하고, 카메라와 로봇을 어떻게 맞추고, 사이클 타임을 어떻게 줄이고, 안전을 어떻게 확보하고, 성능 열화를 어떻게 감지하는가.

8.8가 Nav2의 배치 실무였다면 이 장은 매니퓰레이터의 그것이다.

배우는 것:

• 작업 공간 설계 — 도달성·특이점·여유.
• 핸드아이 캘리브레이션 — 카메라와 로봇 맞추기.
• 사이클 타임 최적화 — 어디를 줄이는가.
• 견고성 설계 — 실패를 전제로.
• 협동 로봇 안전 — 속도·분리 감시.
• 감시와 유지보수 — 열화 감지.
• 배치 절차 — 데모에서 운영까지.

선수 지식: 제9부 전체(9.1~9.5), 7.3(카메라 캘리브레이션), 6.9(진단), 8.8(Nav2 배치 실무 — 대조), 14.10(안전 표준에서 이어받음).

정직: 안전 표준·인증에 관해서는 개념만 다루며, 이 책은 인증 조언을 제공하지 않는다(8.7.1의 반복). 협동 로봇 안전은 ISO/TS 15066 등이 관련되며, 실제 적용은 해당 표준과 전문가·인증기관의 판단을 따라야 한다. 캘리브레이션 도구·패키지의 Jazzy 지원은 확인이 필요하다(확인 필요)(→ 192차 확인: 공식 apt 저장소에 전용 핸드아이 캘리브레이션 패키지가 없음을 직접 조회로 확인했다 — 9.6.4의 실행 확인(192차) 참고). 이 환경에서 검증하지 않았다(목차 3).(→ 192차 확인: 핸드아이 캘리브레이션 도구 유무는 실측했다 — 9.6.4 참고. 안전 인증·나머지 배치 절차는 이번에도 검증하지 않았다.)

9.6.2 데모에서 제품으로

무엇이 달라지는가.

성공률의 산술이 냉혹하다:

$$P_{\text{작업 성공}} = \prod_i P_{\text{단계}_i}$$

12단계(9.5.2) 각각이 99%여도 전체는 $0.99^{12} \approx 89\%$다. 100번 중 11번 실패한다는 뜻이다.

견해: "각 단계를 99.9%로"가 아니라 "실패를 감지하고 복구한다"가 현실적 목표다. 완벽한 단계를 만드는 것보다, 실패를 빠르게 알아채고 저비용으로 재시도하는 시스템이 실제로 더 높은 처리량을 낸다(9.5.8).

9.6.3 작업 공간 설계

로봇을 어디에 두고 작업점을 어디에 배치할 것인가. 이것이 소프트웨어 튜닝보다 큰 영향을 준다.

도달성 확인:

견해: 작업점마다 "IK가 되는가"뿐 아니라 "여유가 있는가"를 확인하라. 겨우 도달하는 위치는 조금만 어긋나도 실패하고, 그 근처가 대개 특이점이거나 관절 한계다. 작업 반경의 중간 영역을 쓰는 것이 견고하다.

특이점 회피(9.4.4):

함정: "거의 다 뻗은 자세"가 가장 흔한 특이점 문제다. 작업점을 로봇 최대 반경 가까이 두면 팔꿈치 특이점에 걸리고, 직선 이동(9.2.6)이 실패한다. 로봇을 조금 가까이 옮기는 것으로 해결되는 경우가 많다.

관절 여유:

견해: 관절이 한계 근처에서 작동하면 계획이 어려워지고 재현성이 떨어진다. 특히 손목 관절이 ±π 근처면 IK 해가 뒤집힐 수 있다. 로봇 베이스 회전이나 작업물 방향을 조정해 여유를 만드는 것이 소프트웨어로 대응하는 것보다 낫다.

배치 검토 절차:

견해: 설치 전에 시뮬로 검토하는 것이 비용이 낮다. 로봇을 볼트로 고정한 뒤 "도달이 안 된다"를 발견하면 재설치 비용이 크다. URDF와 작업점 좌표만 있으면 계획 시험이 가능하다(6.2.8의 mock 하드웨어).

9.6.4 핸드아이 캘리브레이션

카메라가 본 위치를 로봇 좌표로 바꾸려면 둘의 관계를 알아야 한다.

절차(개념):

수학적으로는 $AX = XB$ 형태의 문제다 — 로봇 자세 변화($A$)와 카메라 관측 변화($B$)로부터 고정 변환($X$)을 구한다.

정직: ROS 2용 핸드아이 캘리브레이션 도구의 Jazzy 지원 상태는 확인이 필요하다(확인 필요). MoveIt 캘리브레이션 플러그인이나 별도 패키지가 있으며, 없으면 OpenCV의 관련 함수로 직접 구현하게 된다.(→ 192차 확인: 공식 ROS 2 Jazzy apt 저장소를 직접 조회하니 전용 핸드아이 캘리브레이션 패키지는 없었다 — "MoveIt 캘리브레이션 플러그인" 이름 그대로인 moveit_calibration을 포함해 가장 유력한 후보 4개(easy_handeye2·moveit_calibration·handeye_calibration·visp_hand2eye_calibration) 전부 apt-cache policy에서 완전히 빈 결과(저장소 색인에 이름 자체가 없음)였다. 이 문장의 "없으면"이라는 조건절이 Jazzy 공식 채널에서는 실제로 참이다. 아래 실행 확인(192차) 참고.)

실행 확인(192차) — 이 마커를 실제 apt 조회와 Python 임포트로 직접 확인했다. ros:jazzy-ros-base 컨테이너에서 apt-get update 후 apt-cache policy로 네 개의 유력한 패키지 이름을 각각 조회했다 — ros-jazzy-easy-handeye2(ROS 1 easy_handeye의 가장 자연스러운 ROS 2 이름)·ros-jazzy-moveit-calibration(이 문단이 직접 언급하는 이름)·ros-jazzy-handeye-calibration·ros-jazzy-visp-hand2eye-calibration 넷 다 완전히 빈 출력이었다(설치 안 된 존재하는 패키지라면 최소한 "Installed: (none)"·"Candidate: <버전>"이 나와야 하는데, 그마저도 없었다 — 저장소 색인 자체에 이름이 없다는 뜻). 결론: Jazzy 공식 바이너리 채널에는 전용 핸드아이 캘리브레이션 패키지가 없다. 반면 조립에 필요한 부품들은 실제로 있었다 — 마커 검출용 ros-jazzy-apriltag-ros(3.4.0)·ros-jazzy-aruco-ros(5.0.5), 자체 핸드아이 알고리즘을 가진 비전 라이브러리 ros-jazzy-visp(3.5.0, 전체 libvisp-* 계열도 일반 Ubuntu 패키지로 존재). 그리고 책이 언급한 "OpenCV의 관련 함수"도 실재를 직접 확인했다 — python3-opencv(Ubuntu Noble 표준 OpenCV 4.6.0, Jazzy 환경과 동일)를 설치해 Python에서 직접 hasattr(cv2, 'calibrateHandEye')를 확인하니 True였다. 정직한 결론: "MoveIt 캘리브레이션 플러그인이나 별도 패키지가 있으며"는 이 배포판에서는 아니었고, "없으면 OpenCV의 관련 함수로 직접 구현"이 정확히 현실이다 — 마커 검출 패키지(AprilTag·ArUco)와 cv2.calibrateHandEye()를 조합해 직접 구현해야 한다. 정직한 한계: 공식 apt 채널만 확인했다 — GitHub에만 있고 바이너리로 배포되지 않는 커뮤니티 포트의 존재 여부는 확인하지 않았다. 실제 카메라·로봇으로 종단 캘리브레이션을 수행하지는 않았다(도구 유무만 확인). 원본: tools/gap_harness/gap191/handeye_test/(handeye_check.log·findings_summary.txt).

좋은 캘리브레이션을 위한 지침(7.3.5와 유사):

함정: 회전 없이 병진만 하면 해가 결정되지 않는다. $AX=XB$는 회전 성분에서 정보를 얻으므로, 자세를 여러 방향으로 크게 바꿔야 한다. 이것이 캘리브레이션 실패의 흔한 원인이다.

검증:

견해: "로봇이 마커 중심을 정확히 짚는가"가 가장 직관적인 검증이다. 캘리브레이션 결과로 마커 위치를 계산해 툴 끝을 그곳으로 보내고, 실제로 얼마나 어긋나는지 자로 측정한다. 수 mm 이내면 대부분의 파지에 충분하지만, 정밀 조립에는 더 필요하다.

함정: 캘리브레이션은 어긋난다(7.3.8). 카메라가 충격을 받거나, 마운트가 느슨해지거나, 온도가 변하면 그렇다. 정기 검증 절차를 두고, 파지 성공률이 떨어지면 캘리브레이션을 의심하라.

9.6.5 사이클 타임 최적화

생산성 지표이며, 어디를 줄일지 알아야 한다.

측정이 먼저다:

// 단계별 시간 기록 (6.9)
const auto t0 = now();
perceive();       record("perceive", now() - t0);
const auto t1 = now();
plan();           record("plan", now() - t1);
// ...

견해: "계획 시간"이 예상보다 큰 경우가 많다. OMPL이 수백 ms를 쓰고, 그것이 사이클마다 반복되면 무시할 수 없다. 반복 작업이라면 궤적을 미리 계산해 재생하거나(9.2.4의 비결정성 문제도 함께 해결), Pilz 같은 결정론적 플래너를 쓴다(9.2.5).

견해: 파이프라이닝이 가장 큰 효과를 내는 경우가 많다. 로봇이 물체를 이송하는 동안 다음 물체를 인지하고 계획하면, 그 시간이 사라진다. 순차 실행을 병렬로 바꾸는 것이 개별 단계를 최적화하는 것보다 효과적이다.

함정: 속도를 높이면 다른 문제가 생긴다. 진동, 파지 미끄러짐, 추종 오차 증가, 마모. 속도 상향은 다른 지표를 함께 관찰하며 해야 하며, 성공률이 떨어지면 오히려 처리량이 준다.

$$\text{처리량} = \frac{P_{\text{성공}}}{T_{\text{사이클}}} \cdot (1 - \text{재시도 비용})$$

성공률 하락이 사이클 단축을 상쇄할 수 있다.

9.6.6 견고성 설계

실패를 전제로 시스템을 만든다.

상태 기계로 표현:

견해: 상태 기계를 명시적으로 만들라. 픽앤플레이스는 상태가 많고 전이가 복잡한데, 코드에 흩어져 있으면 어떤 경우가 처리 안 됐는지 모른다. 상태와 전이를 그림으로 그리고 코드가 그것을 따르게 하면 누락이 드러난다.

견해: "사람 개입 경로"를 처음부터 설계하라. 완전 자동화를 목표로 해도 예외는 발생하며, 그때 사람이 안전하게 개입해 복구하고 재개할 수 있어야 한다. 개입 방법이 없으면 라인 전체가 멈춘다.

9.6.7 안전

매니퓰레이터의 안전은 이동 로봇(8.7)과 성격이 다르다.

안전 접근 세 가지:

정직: 협동 로봇 안전은 ISO/TS 15066 등의 표준이 다루며, 이 책은 그 적용을 조언하지 않는다. 힘·압력 한계, 위험성 평가, 검증 방법이 규정되어 있고, 실제 적용은 표준과 전문가·인증기관의 판단을 따라야 한다(14.10).

소프트웨어 계층에서 할 수 있는 것(8.7.7의 구조와 유사):

견해: ③ 힘·전류 감시가 매니퓰레이터 특유의 유용한 계층이다. 예상보다 큰 저항이 감지되면 무언가에 부딪힌 것이므로 즉시 정지한다. ros2_control의 effort 상태 인터페이스(6.1.5)로 구현할 수 있으며, 하드웨어가 제공하면 더 좋다.

견해: ⑤ 없이는 안전 논증이 불가능하다(8.7.7의 반복). 소프트웨어 계층은 소프트웨어가 정상일 때만 동작한다. 안전 정격 하드웨어가 최종 방어선이며, 협동 로봇 제품은 대개 이를 내장한다.

운영 안전 관행:

9.6.8 감시와 유지보수

성능은 서서히 악화된다.

진단 항목(6.9):

견해: 관절 전류 추이가 기계 상태의 좋은 지표다. 같은 동작을 하는데 전류가 서서히 오르면 마찰이 증가한 것 — 윤활·베어링 문제의 조기 신호다. 동일 동작의 전류를 기록해 비교하면 예방 정비 시점을 정할 수 있다.

견해: "기준 동작"을 정해 두고 정기적으로 수행하며 지표를 기록하라. 정해진 자세들을 순회하며 소요 시간·전류·추종 오차를 측정하면, 열화를 추세로 볼 수 있다. 7.6.7의 폐루프 시험과 같은 발상이다.

9.6.9 배치 절차

각 단계 확인:

견해: 8단계 예외 상황 시험이 자주 생략된다(8.8.8의 반복). 물체를 치우고, 잘못된 물체를 놓고, 파지 중에 빼앗고, 통신을 끊어 본다. 정상 흐름만 시험하고 배치하면 예외에서 처음 문제를 만나며, 그때는 라인이 멈춘 상태다.

견해: 7단계에서 충분한 반복을 하라. 10회 성공은 90% 성공률과 구분되지 않는다. 100회 이상 실행해야 1% 수준의 실패율이 보인다. 야간에 무인 반복 시험을 실행하는 것이 흔한 관행이다.

9.6.10 함정 카탈로그

9.6.11 체크포인트

• 데모와 제품의 차이 일곱 축을 말할 수 있는가. 12단계 각 99%일 때 전체 성공률은?
• "실패를 감지하고 복구한다"가 "각 단계를 완벽하게"보다 현실적인 이유는?
• 작업 공간 설계에서 확인할 다섯 가지와, 최대 반경 근처를 피해야 하는 이유는?
• 설치 전 시뮬 검토가 값싼 이유는?
• Eye-in-Hand와 Eye-to-Hand가 각각 무엇을 구하는가.
• 캘리브레이션에 회전이 충분해야 하는 이유와, 가장 직관적인 검증 방법은?
• 사이클 타임 구간 다섯 가지와, 가장 큰 효과를 내는 최적화는?
• 속도 상향이 처리량을 항상 늘리지 않는 이유를 식으로 설명할 수 있는가.
• 견고성 설계 원칙 여섯 가지와, 상태 기계를 명시적으로 만들라는 조언의 근거는?
• 매니퓰레이터 안전이 이동 로봇과 다른 네 축은? 안전 접근 세 가지는?
• 소프트웨어 안전 계층 다섯 단계에서 매니퓰레이터 특유의 것은 무엇인가.
• 열화 항목 일곱 가지와, 관절 전류 추이가 좋은 지표인 이유는?
• 배치 절차 열 단계에서 자주 생략되는 두 단계와, 반복 시험을 100회 이상 해야 하는 이유는?

여기까지가 제9부 매니퓰레이션이다. MoveIt 2 구조(9.1), 계획(9.2), 환경 표현(9.3), 실시간 서보(9.4), 픽앤플레이스 통합(9.5), 그리고 배치 실무(9.6).

제9부가 반복한 것은 셋이다.

1. MoveIt은 "어떻게 갈지"만 답한다. 무엇을 왜 할지, 어디를 정할지는 위에서 정해야 한다(9.1.8·9.5.3). Nav2와 같은 경계다.
2. 환경 모델이 계획을 정한다. Planning Scene이 틀리면 계획이 틀리고, 충돌 기하가 복잡하면 계획이 느리다(9.3). 부착을 잊으면 든 물체가 부딪힌다.
3. 실패를 전제로 설계하라. 단계가 많은 작업은 각 단계가 완벽해도 전체 성공률이 떨어진다. 확인·복구·기록이 성공률보다 중요하다(9.5.8·9.6.2).

이제 로봇은 움직이고, 보고, 길을 찾고, 물건을 다룬다. 그런데 이 모든 것을 실기에서만 개발할 수는 없다 — 위험하고, 느리고, 반복이 어렵다. 가상 환경에서 무엇을 어디까지 검증할 수 있는가가 제10부 시뮬레이션(10.1~10.6) 의 주제다. 시뮬레이션 전략부터 시작한다.

9.6.12 제9부를 마치며 — 매니퓰레이션

이 장은 제9부(9.1~9.6)의 마지막이므로, 부 전체를 하나의 관점으로 묶는다.

제9부가 반복해 말한 세 가지:

1. MoveIt은 설정이 반이다. SRDF·관절 한계·컨트롤러 매핑이 어긋나면 계획은 되는데 실행이 안 된다(9.1·9.5).
2. 오류 코드를 읽어라. MoveItErrorCodes가 원인을 정확히 말해 주는데도 "계획 실패"로만 보고 넘기는 경우가 많다(9.2.12.5).
3. 부드러움은 기본이 아니다. 저크 제한은 켜야 켜지고(9.2.12.4), 시간 파라미터화 결과가 컨트롤러 능력을 넘으면 추종 오차로 나타난다.

다음 부에서 무엇이 달라지나: 제9부까지가 실기에서의 동작이었다면 제10부는 그 앞 단계 — 시뮬레이션이다. 무엇을 시뮬로 검증할 수 있고 무엇이 실기에서만 드러나는가가 이 부의 핵심 질문이다.

제10부는 시뮬레이션(10.1~10.6)다.