콘테스트 프로젝트 진행 상황
각 Quest를 단계적으로 완성하는 프로젝트입니다.
Quest 1: 엣지 AI 기반 자율제조 프레임워크
2026.01.15
Quest 1 제출서: AMFX - 자율제조 프레임워크
프로젝트 개요
프로젝트명
AMFX: Autonomous Manufacturing Framework with Edge AI
(한글명: 엣지 AI 기반 자율제조 프레임워크)
Visual Servoing 로봇 + Agent-in-Loop 자율제조 시스템
한 줄 요약
비전 AI 기반 로봇이 USB 삽입 작업을 자율 수행하고, 이상 발생 시 AI Agent가 자동으로 문제를 해결하는 \;제조 6대 난제 통합 솔루션
1. 프로젝트 목적과 필요성
제조 현장의 문제
| 문제 | 현황 | 결과 |
|---|---|---|
| 반복 작업 | 사람이 수동 수행 | 피로, 실수, 비용 |
| 이상 대응 | 사람이 판단/조치 | 지연, 일관성 부족 |
| 데이터 관리 | 수동 수집/정리 | 누락, 품질 저하 |
| 보안 | 클라우드 의존 | 데이터 유출 위험 |
우리의 해결책
[Physical AI 로봇] + [Edge AI 추론] + [Agent 판단] = 자율제조
- 사람 개입 최소화: 로봇이 반복 작업 자율 수행
- 실시간 이상 대응: AI가 문제 감지 즉시 조치
- 자동 데이터 관리: OTA로 모델/펌웨어 자동 배포
- 온디바이스 보안: 모든 처리가 로컬에서 완료
2. 해결하고자 하는 문제 (6대 난제 통합 해결)
6대 난제 커버리지
핵심 난제 \;(완벽 구현):
| # | 난제 | 적용 방법 | 구현 수준 |
|---|---|---|---|
| ② | 실시간 이상징후 탐지 | 2단계 아키텍처: 로컬 1차 + Agent 2차 판단 | ☆☆☆☆☆ |
| ③ | 품질·\;불량 검사 | USB 삽입 OK/NG 비전 AI 판정 (정확도 95%+ 목표) | ☆☆☆☆☆ |
| ⑤ | 공정 제어·\;최적화 | Visual Servoing Closed-loop + C/T 최적화 | ☆☆☆☆☆ |
부가 기능 \;(프레임워크 확장):
| # | 난제 | 적용 방법 | 구현 수준 |
|---|---|---|---|
| ① | 설비·\;공정 맞춤형 AI | Agent 상황별 판단, OTA 모델 업데이트 | ☆☆☆☆ |
| ④ | 데이터 파이프라인 | Dual ESP32 OTA로 모델/펌웨어 자동 배포 | ☆☆☆☆ |
| ⑥ | 보안 + 온디바이스 | 토큰 인증 + 로컬 AI 추론 + 네트워크 격리 | ☆☆☆☆ |
데모 시나리오: USB 자동 삽입 + PC 포맷 + OS 설치
Phase 1: USB 삽입 (로봇 제어)
1. [시작] 로봇이 부팅 USB 메모리를 집음
2. [비전] 카메라로 노트북 USB 포트 위치 탐지 (YOLO)
3. [제어] Visual Servoing으로 실시간 위치 보정
4. [삽입] USB를 포트에 정확히 삽입
5. [품질] 삽입 성공/실패 AI 판정 (③)
Phase 2: PC 포맷 + OS 설치 자동화 (화면 인식 + 키보드 입력)
6. [화면인식] 화면 캡처 카메라가 노트북 화면 상태 인식
7. [키입력] Arduino Leonardo가 USB HID로 키보드 입력 자동 수행
8. [Agent] 화면 상태에 따라 Agent가 다음 동작 결정
| 화면 상태 | Agent 판단 | 키보드 입력 |
|---|---|---|
| BIOS 진입 필요 | 부팅 설정 | F2/DEL &rarr\; Boot Order 변경 |
| OS 설치 화면 | 설치 진행 | 언어/지역 선택 &rarr\; Next |
| 파티션 선택 | 포맷 + 설치 | 드라이브 선택 &rarr\; Format &rarr\; Next |
| 사용자 설정 | 계정 생성 | 이름/비밀번호 입력 |
| 설치 완료 | 재부팅 | USB 제거 후 Restart |
| 오류 발생 | 복구 시도 | 재시도 또는 HIL 요청 |
Phase 3: 완료 및 로깅
9. [확인] OS 설치 완료 확인 (데스크톱 화면 인식)
10. [로깅] 작업 로그 + C/T 측정 → 공정 최적화 (⑤)
11. [반복] USB 제거 → 다음 PC로 이동
작업 로그 및 C/T 측정 (⑤ 공정 제어·\;최적화 강화)
| 측정 항목 | 설명 | 활용 |
|---|---|---|
| Cycle Time | 작업 1회 소요 시간 | 병목 구간 식별 |
| 단계별 시간 | 탐지/이동/삽입/검증 각각 | 구간별 최적화 |
| 성공률 | OK/NG 비율 | 품질 트렌드 분석 |
| 이상 발생 빈도 | 이상 유형별 카운트 | 예방 조치 |
# 작업 로그 예시
{
"job_id": "USB_INSERT_001",
"timestamp": "2026-01-15T14:30:00",
"cycle_time_ms": 8500,
"steps": {
"detect_port": 1200, # ms
"move_to_port": 3500,
"insert": 2800,
"verify": 1000
},
"result": "OK",
"anomalies": []
}
공정 최적화 루프:
[로그 수집] → [C/T 분석] → [병목 식별] → [파라미터 조정] → [성능 개선]
↓
Agent가 자동으로 최적화 제안
Agent 기반 이상징후 탐지 (①② 통합)
문제: 초기에는 이상 데이터가 없음 &rarr\; 전통적 ML 학습 불가
해결: 상용 Agent (Claude)를 활용한 Human-in-the-Loop (HIL) 설계
Phase 1 이상징후: 로봇 제어 (Visual Servoing)
| 이상 상황 | Agent 감지 방법 | 자동 대응 | HIL 요청 |
|---|---|---|---|
| 카메라 결착 불안정 | 보정값 지속 증가 추적 | 자동 캘리브레이션 | "\;보정값 +5mm 누적. 물리적 점검 필요?"\; |
| 기계적 틀어짐 | 위치 오차 패턴 분석 | 오프셋 보정 적용 | "\;축 정렬 이상 감지. 유지보수 필요?"\; |
| 서보 모터 이상 | 전류/토크 이상 탐지 | 속도 제한 적용 | "\;모터 과부하. 교체 필요?"\; |
| USB 포트 인식 실패 | YOLO 탐지 실패 횟수 | 재탐지 시도 | "\;포트 인식 3회 실패. 조명/각도 조정?"\; |
[보정값 로그] → [Agent 트렌드 분석] → 정상 범위 → [계속 운영]
↓
임계값 초과 (예: +5mm)
↓
[HIL 요청: "물리적 점검 필요?"]
↓
[사람 확인 → 유효 이상징후 DB 업데이트]
Agent 기반 자동 수정:
- 예상과 다른 동작 발생 시 Agent가 \;제어 파라미터 조정
- 반복 실패 시 Agent가 \;펌웨어 설정 수정 제안
- 모든 수정 이력은 로그로 저장 &rarr\; 추후 분석
Phase 2 이상징후: PC 포맷 + OS 설치 (화면 인식)
| 이상 상황 | Agent 감지 방법 | 자동 대응 | HIL 요청 |
|---|---|---|---|
| BIOS 진입 실패 | 화면 상태 미변경 | F2/DEL/F12/ESC 순차 시도 | "\;BIOS 진입 불가. 키 조합 추가?"\; |
| 부팅 순서 변경 불가 | BIOS 메뉴 인식 실패 | 다른 BIOS UI 패턴 시도 | "\;미지원 BIOS. 매뉴얼 필요?"\; |
| 파티션 오류 | 설치 화면 에러 메시지 | 다른 파티션 선택 시도 | "\;디스크 에러. 수동 확인 필요?"\; |
| 설치 중단 | 진행률 정체 감지 | 재시작 시도 | "\;설치 30분 정체. 강제 재시작?"\; |
| 드라이버 누락 | 설치 완료 후 오류 | 드라이버 USB 삽입 시도 | "\;네트워크 드라이버 누락. 추가 USB?"\; |
[화면 상태] → [Agent 판단: BIOS 진입 필요]
↓
[F2 전송] → 실패 → [DEL 전송] → 실패 → [F12 전송]
↓ ↓
성공 3회 실패 시
↓ ↓
[다음 단계 진행] [HIL: "키 조합 추가 필요?"]
↓
[사람 입력: "F10 사용"]
↓
[BIOS 키 DB 업데이트]
Phase 3 이상징후: 완료 및 반복
| 이상 상황 | Agent 감지 방법 | 자동 대응 | HIL 요청 |
|---|---|---|---|
| OS 부팅 실패 | 데스크톱 미표시 | 재설치 시도 | "\;부팅 실패. 이미지 손상?"\; |
| USB 제거 실패 | 로봇 그리퍼 오류 | 재시도 + 힘 조절 | "\;USB 걸림. 수동 제거 필요?"\; |
| C/T 이상 증가 | 평균 대비 +20% | 병목 구간 분석 | "\;특정 단계 지연. 원인 분석?"\; |
이상징후 DB 구조
{
"anomaly_id": "ANM_001",
"phase": "phase1",
"type": "calibration_drift",
"detected_by": "agent",
"pattern": "correction_value >\; 5mm for 10 cycles",
"auto_response": "recalibrate",
"hil_response": "physical_inspection_needed",
"human_feedback": "camera_mount_loose",
"resolution": "tighten_mount",
"valid": true,
"timestamp": "2026-01-16T10:30:00"
}
장점:
- 데이터 없이도 \;즉시 운영 가능
- Agent가 \;맥락을 이해하고 판단
- HIL로 \;점진적 자동화 \;달성
- 예상치 못한 상황에도 \;유연하게 대응
- Phase별 이상징후 DB 축적 &rarr\; \;지속적 개선
Agent 구현: 2단계 아키텍처
온디바이스 우선 + 클라우드 보조 설계:
[센서 데이터] → [1차 판단: 로컬] → 확정 시 → [즉시 조치]
↓
미확정 시 (10% 미만)
↓
[2차 판단: Cloud Agent]
| 단계 | 구현 | 역할 | 네트워크 |
|---|---|---|---|
| 1차 | 규칙 기반 + 경량 ML (TFLite) | 90% 상황 처리 | 불필요 |
| 2차 | Claude API | 예외/신규 상황 | 필요 시만 |
장점:
- 네트워크 단절 시에도 \;1차 판단으로 운영 지속
- 90% 이상 상황은 \;완전 온디바이스로 처리
- 클라우드는 \;예외 상황에만 \;사용 &rarr\; 보안 + 비용 최적화
본 프로젝트는 \;향후 완전 온디바이스 AI로 확장 가능하도록 설계됩니다. 축적된 경험 데이터를 활용해 경량 Foundation Model을 학습하면, 2차 판단까지 로컬에서 처리 가능합니다.
3. 활용할 센서·\;모듈
하드웨어 구성
┌─────────────────────────────────────────────────────────┐
│ Jetson Xavier (AI 허브) │
│ ┌─────────────┐ ┌─────────────┐ │
│ │ CAM1: USB │ │ CAM2: 화면 │ YOLO + 화면 인식 │
│ │ 포트 탐지 │ │ 상태 캡처 │ + Agent 연동 │
│ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────┘
│ 이더넷 │ Serial │ Serial
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌───────────────┐
│ RPI5 8GB │ │ ESP32-S3 │ │ Arduino │
│ (데이터 허브) │ │ (로봇 제어) │ │ Leonardo │
│ 로깅, OTA서버 │ │ 서보, IMU │ │ (키보드 HID) │
│ 대시보드 │ │ │ │ │
└───────────────┘ └───────────────┘ └───────────────┘
DigiKey 보유 보유 (노트북 USB 허브)
역할 분리: AI 허브 vs 데이터 허브
| 허브 | 장치 | 역할 |
|---|---|---|
| AI 허브 | Jetson Xavier | 비전 AI (듀얼 카메라), Agent 연동, 실시간 판단 |
| 데이터 허브 | RPI5 8GB | 작업 로그, C/T 측정, OTA 서버, 대시보드 |
Dual ESP32 OTA 시스템 (④ 데이터 파이프라인 핵심 기술)
문제: 제조 현장에서 다수의 ESP32 기반 제어기 펌웨어/모델 업데이트가 필요
해결: RPI5를 OTA 서버로 활용 + esp-serial-flasher로 디바이스 간 플래싱
OTA 아키텍처
┌─────────────────────────────────────────────────────────────┐
│ RPI5 (OTA 서버) │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Flask API │ │ 펌웨어 저장 │ │ 버전 관리 │ │
│ │ /firmware/* │ │ *.bin │ │ version.json│ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
└─────────────────────────────────────────────────────────────┘
│ Wi-Fi (HTTP OTA)
▼
┌───────────────────┐
│ ESP32-S3 │ ← HTTP Update (ElegantOTA)
│ (로봇 제어 MCU) │
│ │ ← esp-serial-flasher 내장
└───────────────────┘
│ Serial (UART: TX/RX + BOOT/EN)
▼
┌───────────────────┐
│ ESP32-C3 │ ← Serial Flashing
│ (보조 MCU/센서) │ (파티션 제한 없음)
└───────────────────┘
OTA 방식 비교
| 방식 | 설명 | 장점 | 단점 |
|---|---|---|---|
| HTTP OTA | Wi-Fi로 서버에서 .bin 다운로드 | 무선, 원격 가능 | 네트워크 필요, 파티션 제한 |
| esp-serial-flasher | ESP32가 다른 ESP32를 시리얼로 플래싱 | 파티션 무관, 전체 플래시 교체 | 유선 연결 필요 |
esp-serial-flasher 활용 (Espressif 공식 라이브러리)
하드웨어 연결:
ESP32-S3 (Host) ESP32-C3 (Target)
\--\--\--\--\--\--\--- \--\--\--\--\--\--\--\---
IO26 → IO0 (BOOT)
IO25 → EN (RESET)
IO4 (TX) → RX0
IO5 (RX) → TX0
GND → GND
플래싱 프로세스:
1. [RPI5] HTTP로 새 펌웨어 .bin → [ESP32-S3]
2. [ESP32-S3] 자신의 펌웨어 업데이트 (HTTP OTA)
3. [ESP32-S3] esp-serial-flasher로 [ESP32-C3] 플래싱
4. [ESP32-C3] 부트로더 모드 진입 (BOOT LOW + EN 토글)
5. [ESP32-C3] 전체 플래시 교체 완료
장점:
- 파티션 크기 제한 우회: 일반 OTA는 ota_0/ota_1 두 파티션 필요 (각 ~1.5MB)
- 대용량 펌웨어: esp-serial-flasher는 전체 플래시 교체 가능
- 네트워크 불필요: 시리얼만으로 타겟 디바이스 업데이트
- 안전한 롤백: 실패 시 이전 파티션으로 자동 복구
버전 관리 시스템
# RPI5: version.json
{
"esp32_s3": {
"version": "1.2.0",
"url": "/firmware/esp32_s3_v1.2.0.bin",
"sha256": "abc123..."
},
"esp32_c3": {
"version": "1.1.0",
"url": "/firmware/esp32_c3_v1.1.0.bin",
"sha256": "def456..."
}
}
# ESP32-S3: 자동 업데이트 체크
def check_ota_update():
response = http_get("http://rpi5:5000/firmware/latest")
if response["version"] >\; current_version:
download_and_flash(response["url"])
# ESP32-C3도 업데이트 필요 시
if c3_update_available:
serial_flash_esp32_c3(response["c3_url"])
TFLite 모델 OTA (① 설비 맞춤형 AI)
펌웨어뿐 아니라 \;AI 모델도 OTA로 업데이트:
[Agent 학습 결과] → [새 TFLite 모델] → [RPI5 서버]
↓
[ESP32-S3 다운로드]
↓
[SPIFFS/LittleFS 저장]
↓
[새 모델로 추론]
| 업데이트 대상 | 용량 | 주기 |
|---|---|---|
| 펌웨어 (.bin) | ~1MB | 필요 시 |
| TFLite 모델 (.tflite) | ~500KB | Agent 학습 후 |
| 설정 파일 (.json) | ~10KB | 파라미터 변경 시 |
부품 상세
RPI5 8GB 선택 이유 (데이터 허브)
| 요구사항 | RPI5 8GB 적합성 |
|---|---|
| 작업 로깅 | C/T 측정, 작업 로그 저장 및 분석 |
| OTA 서버 | ESP32 펌웨어/모델 배포 서버 운영 |
| 대시보드 서빙 | Flask/Streamlit 웹 서버 + 실시간 데이터 시각화 |
Jetson Xavier는 AI 허브 (비전 + Agent), RPI5는 \;데이터 허브 \;(로깅 + OTA)로 역할 분리하여 ④ 데이터 파이프라인 난제 강화
| 구분 | 부품 | 역할 | 조달 |
|---|---|---|---|
| AI | Jetson Xavier | YOLO (듀얼 카메라) + 화면 인식 + Agent 연동 | 보유 |
| 데이터 | Raspberry Pi 5 8GB | 로깅, OTA 서버, 대시보드 (④ 데이터 파이프라인) | DigiKey |
| 제어 | ESP32-S3 | 로봇 서보 제어, 센서 수집 | 보유 |
| 키보드 | Arduino Leonardo | USB HID 키보드 입력 (노트북 USB 허브 연결) | 보유 |
| OTA | ESP32-C3 | 펌웨어 OTA 수신 | 보유 |
| 카메라 | USB CAM x2 | CAM1: USB 포트 탐지, CAM2: 화면 캡처 | 보유/국내구매 |
| IMU | MPU6050 | 로봇 자세/진동 감지 | 보유/국내구매 |
| 전류 | INA219 | 로봇 이상 탐지 | 보유/국내구매 |
| 서보 | MG996R x4 | 로봇 관절 구동 (고토크/정밀) | 보유/국내구매 |
4. 기술 스택
소프트웨어
| 분야 | 기술 | 용도 |
|---|---|---|
| AI 모델 | YOLO, MobileNet | 객체탐지, 분류 |
| 경량화 | TFLite, ONNX | 엣지 배포 |
| 제어 | Visual Servoing | 실시간 로봇 제어 |
| 통신 | MQTT | 디바이스 간 통신 |
| OTA | esp-serial-flasher, ElegantOTA | ESP32 펌웨어/모델 원격 업데이트 |
| Agent | Claude API | 예외 상황 자동 판단 |
| 대시보드 | Flask/Streamlit | 실시간 모니터링 |
핵심 알고리즘
Visual Servoing (⑤ 공정제어)
while not inserted:
image = camera.capture()
target = yolo.detect(image, "usb_port")
error = calculate_error(current_pos, target)
servo.move(pid_control(error))
이상징후 탐지 (②)
def detect_anomaly():
current = ina219.read() # 전류 이상
position = servo.get_pos() # 위치 오차
vibration = mpu6050.read() # 진동 패턴
if current >\; threshold or position_error >\; limit:
return "ANOMALY"
품질 검사 (③)
def check_insertion_quality():
image = camera.capture()
result = model.predict(image) # OK / NG / PARTIAL
return result
5. 보안 설계 (⑥)
3단계 보안 아키텍처
| 단계 | 방법 | 효과 |
|---|---|---|
| 1 | 로컬 네트워크 격리 | 외부 공격 원천 차단 |
| 2 | 토큰 기반 디바이스 인증 | 미등록 장치 차단 |
| 3 | 온디바이스 AI 추론 | 데이터 외부 유출 방지 |
통신 보안
[ESP32] ──── "DEVICE_TOKEN" ────? [RPI5]
│
토큰 검증 후만 통신
6. DigiKey 부품
| 품목 | DigiKey URL | 가격 |
|---|---|---|
| Raspberry Pi 5 8GB | SC1431 | $95 |
나머지 부품은 보유품 + 국내 구매로 조달
7. 차별화 포인트
vs 경쟁작 비교
| 항목 | 경쟁작 (대부분) | AMFX (우리) |
|---|---|---|
| 난제 커버리지 | 1~2개 | 6개 전체 |
| 제어 방식 | Open-loop | Closed-loop |
| AI 수준 | FFT, 고정 모델 | Visual Servoing + Agent |
| 이상 대응 | 알람만 | 자동 복구 |
| 보안 | 미언급 | 온디바이스 + 인증 |
| 데모 | 그래프/콘솔 | 실물 로봇 동작 |
핵심 차별점 3가지
- 핵심 난제 완벽 해결 + 전체 커버: ②③⑤ 완벽 구현 + 나머지 프레임워크 지원
- 2단계 Agent 아키텍처: 90% 온디바이스 + 10% 클라우드 보조 (네트워크 단절 대응)
- Physical AI 데모: 실제 로봇이 USB를 삽입하는 시각적 임팩트
8. 개발 계획
Quest 2 (01.17 ~ 02.15)
| 주차 | 목표 |
|---|---|
| 1~2주 | H/W 조립, 기본 통신 구축 |
| 3~4주 | Visual Servoing 구현, YOLO 학습 |
Quest 3 (02.16 ~ 03.01)
| 주차 | 목표 |
|---|---|
| 1주 | 통합 테스트, 이상탐지 튜닝 |
| 2주 | 데모 완성, 문서화, 영상 제작 |
9. 기대 효과
정량적 효과 (예시)
| 지표 | 현재 (수동) | AMFX 적용 후 |
|---|---|---|
| 작업 시간 | 30초/회 | 10초/회 |
| 오류율 | 5% | <\;1% |
| 이상 대응 시간 | 수 분 | 수 초 |
확장 가능성
- 다양한 작업: USB 삽입 &rarr\; 커넥터 체결, 부품 조립 등
- 다양한 플랫폼: RPI5 &rarr\; Jetson, 산업용 PLC 등
- 다양한 규모: 단일 로봇 &rarr\; 다중 로봇 협업
10. 요약
AMFX는 제조 현장의 \;핵심 난제 3개(②③⑤)를 완벽 해결하고, 나머지 난제까지 통합 지원하는 프레임워크입니다.
| 핵심 기술 | 설명 |
|---|---|
| Physical AI | 실제 로봇이 작업 수행 (MG996R 고정밀 서보) |
| 2단계 Edge AI | 90% 로컬 처리 + 10% 클라우드 보조 |
| Visual Servoing | 실시간 비전 피드백 Closed-loop 제어 |
| Agent-in-Loop | 예외 상황 자동 판단/복구 |
| OTA | 자동 모델/펌웨어 업데이트 |
| 보안 | 온디바이스 우선 + 토큰 인증 |
"\;단순한 아이디어가 아닌, \;작동하는 자율제조 시스템을 구현합니다."\;
작성일: 2026.01.15
제출: Industrial Edge AI Solution Challenge 2026 Quest 1
Quest 2: 엣지 AI 기반 자율제조 프레임워크- 중간 공유
2026.02.15
\;
\;
1. 프로젝트 개요
목표
6축 로봇팔 + Edge AI + Agent를 결합하여 \;USB 삽입 &rarr\; PC 포맷 &rarr\; OS 설치를 자율로 수행하는 산업용 엣지 AI 시스템.
핵심 기술
| 기술 요소 | 설명 |
|---|---|
| Visual Servoing | 카메라 피드백 기반 로봇 위치 보정 (Eye-to-Hand) |
| Agent-in-Loop | Claude API 기반 자율 판단 + Human-in-the-Loop 개입 |
| 이상징후 탐지 | 전류 센서(INA219) 기반 실시간 모니터링 |
| 실시간 대시보드 | Flask + Socket.IO 기반 웹 모니터링 |
2. 부품 구매 및 하드웨어 현황
2.1 DigiKey 구매 (인보이스 Quest 3 제출)
| 품목 | DigiKey 주문 | 가격 | 상태 |
|---|---|---|---|
| Raspberry Pi 5 8GB | SC1431 | ~100,000원 ($95 USD) | 수령 완료 |
DigiKey 구매 인보이스는 Quest 3에서 제출합니다.
2.2 추가 구매 (국내)
| 부품 | 용도 | 상태 |
|---|---|---|
| PCA9685 \;(16채널 I2C PWM 보드) | 6축 서보 제어 | 배송 대기 (02.16) |
PCA9685는 RPI4에서 I2C로 6축 서보를 직접 제어하기 위한 필수 부품입니다. 기존 ESP32-S3로도 제어 가능하나, I2C 방식이 펌웨어 개발 없이 Python 라이브러리로 즉시 제어 가능하여 PCA9685를 선택했습니다. 배송 수령 후 즉시 하드웨어 통합에 착수합니다.
2.3 보유 장비 활용
| 장비 | 원래 계획(v1) | 실제 활용(v2) | 상태 |
|---|---|---|---|
| 6축 로봇팔 \;(MG996R x6) | 4DOF SG90 x4 | 6DOF MG996R x6으로 업그레이드 | 조립 완료 |
| Raspberry Pi 5 | 메인 컨트롤 허브 | DigiKey 주문 예정 | 주문 예정 |
| Raspberry Pi 4 | 백업/테스트 | 개발 중 메인 허브로 활용 (Flask 서버) | 보유 |
| Jetson Xavier NX \;+ NX215AG | AI 허브 (미정) | AI 허브 확정 (YOLO, Agent, HDMI 캡처) | 셋업 완료 |
| Raspberry Pi Pico | - | USB HID 에뮬레이션 (키보드/마우스) | 보유 |
| ESP32-S3 \;x2 | 서보 PWM 직접 제어 | 예비 (확장/백업용) | 보유 |
| Arduino Leonardo | USB HID 메인 | HID 백업 | 보유 |
| USB 웹캠 | Visual Servoing | 탑뷰 카메라 (변경 없음) | 보유 |
| 5V 5A PSU | 6V 10A 별도 구매 예정 | 보유 5V PSU로 대체 (MG996R 동작범위 4.8~7.2V) | 보유 |
3. 설계 변경 사항 (v1 &rarr\; v2)
Quest 1 제출 시점의 초기 설계(v1)와 실제 하드웨어 확보 후 변경된 현재 설계(v2)의 차이:
| 항목 | v1 (초기 설계) | v2 (현재) | 변경 이유 |
|---|---|---|---|
| 로봇 | 4DOF, SG90 x4 | 6DOF, MG996R x6 | 6축 로봇팔 확보로 자유도 증가 |
| 서보 제어 | ESP32-S3 PWM 직접 제어 | PCA9685 I2C 보드 | 펌웨어 불필요, Python 직접 제어 |
| 메인 허브 | Raspberry Pi 5 (주문 예정) | Raspberry Pi 4 \;(개발용) | 보유 RPI4로 즉시 개발 착수 |
| AI 허브 | Jetson Xavier (미확정) | Jetson Xavier NX + NX215AG | 캐리어보드 포함 확보 완료 |
| USB HID | Arduino Leonardo (전용) | RPi Pico (CircuitPython) | 보유, adafruit_hid로 간편 구현 |
| 전원 | 6V 10A 별도 PSU | 보유 5V 5A PSU | MG996R 4.8~7.2V 호환, 추가 구매 불필요 |
| ESP32-C3 | OTA/WiFi 관리 | 제거 | MVP에 불필요, 복잡도 감소 |
| 통신 | MQTT + Serial | REST/WebSocket + Serial | MQTT 브로커 제거로 간소화 |
| DB | InfluxDB + SQLite | SQLite 단일 | MVP에서 시계열 DB 불필요 |
변경의 핵심 원칙
"\;보유 장비를 최대한 활용하고, 추가 구매는 최소화하여 빠르게 동작하는 프로토타입을 완성한다."\;
- PCA9685 1개만 추가 배송되면 전체 하드웨어 구성이 완료됨
- 소프트웨어는 시뮬레이션 모드로 하드웨어 도착 전에 전체 로직을 구현 완료
4. 소프트웨어 개발 현황
4.1 구현 완료 항목 (40개 파일, ~317KB)
전체 소프트웨어는 \;시뮬레이션 모드(SIMULATE_HARDWARE=True)로 하드웨어 없이 개발 및 테스트가 가능하도록 설계했습니다. PCA9685 수령 후 \;SIMULATE_HARDWARE=False로 전환하면 실제 하드웨어와 즉시 연동됩니다.
Backend (Flask + Socket.IO) - 21 파일
| 모듈 | 파일 | 설명 | 상태 |
|---|---|---|---|
| Core | app/__init__.py |
Flask 앱 팩토리, CORS, Socket.IO | 완료 |
| Core | app/config.py |
개발/프로덕션/테스트 설정 | 완료 |
| Core | run.py |
서버 엔트리포인트 (CLI) | 완료 |
| API | api/robot.py |
6축 로봇 제어 REST API | 완료 |
| API | api/job.py |
작업 관리 API | 완료 |
| API | api/hil.py |
Human-in-Loop API | 완료 |
| API | api/anomaly.py |
이상징후 관리 API | 완료 |
| API | api/system.py |
시스템 상태 API | 완료 |
| API | api/socket_events.py |
WebSocket 이벤트 핸들러 | 완료 |
| Hardware | hardware/pca9685_driver.py |
PCA9685 6축 서보 드라이버 | 완료 |
| Hardware | hardware/sensor_reader.py |
INA219 전류/전압 센서 | 완료 |
| Hardware | hardware/serial_manager.py |
UART 시리얼 통신 | 완료 |
| Service | services/robot_service.py |
로봇 제어 비즈니스 로직 | 완료 |
| Service | services/job_service.py |
작업 스케줄링 + Phase 관리 | 완료 |
| Service | services/hil_service.py |
Agent &harr\; Human 의사결정 | 완료 |
| Service | services/anomaly_service.py |
이상징후 탐지 + 자동 비상정지 | 완료 |
| Service | services/jetson_client.py |
Jetson AI 서버 HTTP 클라이언트 | 완료 |
| Model | models/database.py |
SQLite ORM (jobs, anomalies, HIL) | 완료 |
Dashboard (Web UI) - 4 파일
| 파일 | 설명 | 상태 |
|---|---|---|
templates/index.html |
대시보드 메인 (6축 표시, 차트, HIL) | 완료 |
static/css/main.css |
다크/라이트 테마, 반응형 | 완료 |
static/js/app.js |
Socket.IO 실시간 업데이트, 데모 모드 | 완료 |
app.py |
대시보드 Flask 앱 | 완료 |
Jetson AI Server (FastAPI) - 7 파일
| 파일 | 설명 | 상태 |
|---|---|---|
main.py |
FastAPI 서버 (/detect, \;/agent/decide, \;/screen) |
완료 |
vision/yolo_detector.py |
YOLO v8 객체 탐지 (USB 포트, 그리퍼 등) | 완료 |
agent/claude_agent.py |
Claude API Agent (자율 의사결정) | 완료 |
servoing/visual_servo.py |
Visual Servoing PID 제어 | 완료 |
Firmware - 5 파일
| 파일 | 설명 | 상태 |
|---|---|---|
firmware/pico/code.py |
RPi Pico CircuitPython USB HID | 완료 |
firmware/esp32_s3/main/main.c |
ESP32-S3 FreeRTOS (예비) | 완료 |
firmware/arduino_leonardo/amfx_hid.ino |
Arduino HID (백업) | 완료 |
4.2 시스템 아키텍처
┌──────────────────────────────────────────────────────────────────┐
│ AMFX System Architecture v2 │
├──────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ Jetson Xavier NX (AI Hub) │ │
│ │ AverMedia NX215AG Carrier │ │
│ │ │ │
│ │ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌──────────┐│ │
│ │ │ USB Camera │ │HDMI Capture│ │ YOLO v8 │ │Claude API││ │
│ │ │ (Top View) │ │ (NX215AG) │ │ Detector │ │ Agent ││ │
│ │ └──────┬─────┘ └──────┬─────┘ └──────┬─────┘ └────┬─────┘│ │
│ │ │ │ │ │ │ │
│ │ ┌──────┴───────────────┴──────────────┴─────────────┴────┐│ │
│ │ │ FastAPI AI Server (:8000) ││ │
│ │ └────────────────────────┬────────────────────────────────┘│ │
│ └───────────────────────────┼──────────────────────────────────┘ │
│ │ HTTP/REST │
│ ┌───────────────────────────┼──────────────────────────────────┐ │
│ │ Raspberry Pi 4 (Control Hub) │ │
│ │ │ │
│ │ ┌──────────────────────────────────────────────────────┐ │ │
│ │ │ Flask + Socket.IO Server (:5000) │ │ │
│ │ └─────────────────────────┬──────────────────────────────┘ │ │
│ │ │ │ │
│ │ ┌───────────┐ ┌──────┴──────┐ ┌─────────────┐ │ │
│ │ │ PCA9685 │ │ INA219 │ │ RPi Pico │ │ │
│ │ │ I2C PWM │ │ I2C 센서 │ │ USB HID │ │ │
│ │ └─────┬─────┘ └─────────────┘ └──────┬──────┘ │ │
│ │ ┌─────┴─────┐ ┌────┴─────┐ │ │
│ │ │ MG996R x6 │ │ Target PC│ │ │
│ │ │ 6축 로봇팔 │ │ (포맷대상)│ │ │
│ │ └───────────┘ └──────────┘ │ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────────────┐ │
│ │ Web Dashboard (Socket.IO 실시간 모니터링) │ │
│ └──────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
5. 구현 순서 및 일정
5.1 완료된 작업 (Quest 2 기간: 01.17~02.15)
| 주차 | 기간 | 작업 내용 | 산출물 | 상태 |
|---|---|---|---|---|
| W1 | 01.17-01.24 | 아이디에이션, 시스템 설계 | system_architecture.md, \;ideation_log.md |
완료 |
| W2 | 01.25-01.31 | 대시보드 설계, 프론트엔드 리서치 | dashboard_design.md, Dashboard HTML/CSS/JS |
완료 |
| W3 | 02.01-02.07 | Backend API 구현 (Flask + Socket.IO) | REST API 8개 엔드포인트, WebSocket 6개 이벤트 | 완료 |
| W4 | 02.08-02.14 | 하드웨어 드라이버, AI 서버, 서비스 레이어 | PCA9685 드라이버, Jetson AI 서버, 전체 서비스 | 완료 |
| W4 | 02.15 | v2 아키텍처 확정, 로봇 조립, 코드 통합 | system_architecture_v2.md, 40개 파일 통합 |
완료 |
5.2 남은 작업 및 개발 계획 (Quest 3 기간: 02.16~03.01)
Phase A: 하드웨어 통합 (02.16~02.20, 5일)
| 일자 | 작업 | 상세 | 완료 기준 |
|---|---|---|---|
| 02.16 | PCA9685 구매 | 국내 온라인 주문 | 주문 완료 |
| 02.17-18 | PCA9685 수령 + I2C 연결 | RPI4 &harr\; PCA9685 배선, I2C 주소 확인 | i2cdetect로 0x40 감지 |
| 02.18-19 | 서보 개별 테스트 | 6축 각 관절 PWM 범위 캘리브레이션 | 6축 모두 정상 회전 |
| 02.19-20 | INA219 센서 연결 | 전류/전압 모니터링 검증 | 실시간 전류값 대시보드 표시 |
현재 전체 소프트웨어가 시뮬레이션 모드(SIMULATE_HARDWARE=True)로 동작 중이므로, PCA9685 수령 즉시 \;False로 전환하여 실제 하드웨어 연동이 가능합니다.
Phase B: 디바이스 연동 (02.21~02.24, 4일)
| 일자 | 작업 | 상세 | 완료 기준 |
|---|---|---|---|
| 02.21 | RPi Pico HID 연동 | CircuitPython 펌웨어 업로드, UART 통신 | 타겟 PC에 키 입력 성공 |
| 02.22 | Jetson 카메라 연동 | USB 웹캠 + HDMI 캡처 테스트 | 카메라 피드 정상 수신 |
| 02.23 | YOLO 모델 학습 | USB 포트 커스텀 데이터셋 학습 | mAP@50 >\; 85% |
| 02.24 | Visual Servoing 테스트 | 카메라 &rarr\; 로봇 보정 루프 검증 | 타겟 ±\;5mm 정밀도 |
Phase C: End-to-End 통합 (02.25~03.01, 5일)
| 일자 | 작업 | 상세 | 완료 기준 |
|---|---|---|---|
| 02.25-26 | 전체 데모 시나리오 테스트 | USB 삽입 &rarr\; BIOS &rarr\; OS 설치 연속 동작 | 1회 이상 성공 |
| 02.27 | Agent HIL 통합 | Claude Vision 화면 분석 + 자율 판단 | 3개 시나리오 대응 |
| 02.28 | 이상징후 시나리오 테스트 | 과전류, 스톨, 전압 이상 시 자동 비상정지 | 비상정지 정상 동작 |
| 03.01 | 최종 정리 | 버그 수정, 문서화, Quest 3 제출 준비 | 제출 완료 |
5.3 개발 방식
| 항목 | 방식 |
|---|---|
| 개발 전략 | 시뮬레이션 모드로 로직 먼저 완성 &rarr\; 하드웨어 도착 후 즉시 통합 |
| 형상 관리 | Git (GitHub private repository) |
| AI 도구 | Claude Code (Opus 4.6) 활용 AI-Native 개발 |
| 테스트 | pytest 단위 테스트 + 시뮬레이션 통합 테스트 |
| 리스크 관리 | ESP32-S3, Arduino Leonardo를 백업으로 보유 |
6. 데모 시나리오
[Phase 1] USB 삽입
로봇 Home → USB 파지 → Visual Servoing으로 USB 포트 탐지 → 정밀 삽입
[Phase 2] OS 설치
Pico HID로 타겟 PC 키보드 제어 → BIOS 진입 (F2/DEL)
→ 부팅 순서 변경 → USB 부팅 → Windows 설치 자동 진행
[Phase 3] Agent 자율 판단
HDMI 화면 캡처 → Claude Vision 분석 → 다음 행동 결정
→ 예상치 못한 상황 발생 시 Agent HIL로 운영자 개입 요청
[Phase 4] 완료
설치 완료 확인 → USB 제거 → 로봇 Home 복귀
→ 대시보드에 전체 작업 리포트 표시
7. 로봇팔 조립 사진
[사진 첨부 예정] \;6축 로봇팔 (MG996R x6) 조립 완료 상태
8. 대시보드 스크린샷
대시보드는 시뮬레이션 모드에서 동작 확인 완료:
- 6축 관절 각도 실시간 표시 (Base, Shoulder, Elbow, W.Pitch, W.Roll, Gripper)
- 서보 전류 / 전압 게이지
- 작업 진행률 (Phase 단위)
- Agent HIL 패널 (AI 질문 &rarr\; 운영자 응답)
- Cycle Time 트렌드 차트
- Anomaly Log (이상징후 실시간 로그)
- 시스템 상태 바 (RPI4, PCA9685, Jetson NX, Pico HID, INA219)
9. 기술 스택 요약
| 레이어 | 기술 | 버전 |
|---|---|---|
| Backend | Flask + Socket.IO | 3.0 / 5.3 |
| Frontend | Jinja2 + Chart.js + Socket.IO Client | 4.7.5 |
| AI Server | FastAPI + YOLO v8 + Claude API | - |
| MCU | CircuitPython (Pico) + ESP-IDF (ESP32) | - |
| DB | SQLite | 3.x |
| 통신 | REST / WebSocket / UART (115200bps) | - |
| 전원 | 5V 5A PSU &rarr\; PCA9685 &rarr\; MG996R x6 | - |
10. 구매 인보이스
DigiKey 구매 (Quest 1)
| 품목 | DigiKey Part | 가격 | 상태 |
|---|---|---|---|
| Raspberry Pi 5 8GB | SC1431 | $95 USD (~100,000원) | 주문 예정 |
DigiKey 구매 인보이스는 Quest 3에서 별도 제출합니다.
Quest 3: 엣지 AI 기반 자율제조 프레임워크 - 삽질에서 깨달음까지
2026.03.01
\;
엣지 AI 기반 자율제조 프레임워크 &mdash\; 삽질에서 깨달음까지
Industrial Edge AI Solution Challenge 2026 \;Team Davinci \;| AMFX: Autonomous Manufacturing Framework with Edge AI
1. 처음 만난 PC를 포맷해야 합니다
수작업 절차
어떤 PC든 처음 받으면 하는 일:
1. 전원 버튼을 누른다
2. BIOS에 들어가 부팅 순서를 바꾼다
3. USB 설치 디스크를 꽂는다
4. OS를 설치한다 (언어, 키보드, 파티션, 사용자...)
5. 초기 설정을 한다
사람이 모니터 앞에 앉아서, 수십 번 키보드를 치는 반복 작업. \;공장에서 100대, 1000대를 세팅한다면?
로봇과 자동화한다면?
빈 PC 앞에 로봇을 놓고,
전원을 켜고,
BIOS를 설정하고,
OS를 설치한다.
사람 개입 = 0
이걸 하려면 로봇이 해야 할 일: \;보고(카메라) &rarr\; \;판단하고(AI) &rarr\; \;움직이고(IK) &rarr\; \;조작한다(HID)
6대 난제를 해결하기 위해 &mdash\; 직접 공정을 만들었다
난제를 "\;선택"\;한 것이 아니다. \;직접 공정을 만들어 데이터를 발생시켰더니, 6대 난제가 \;정말로 자연 발생했고, 하나씩 삽질하면서 해결했다.
로봇이 목표를 찾는다 → 위치가 틀리면? → ⑤ 공정 제어
로봇이 버튼을 누른다 → 힘이 과하면? → ② 이상징후
화면을 읽어야 한다 → OCR이 안 되면? → ③ 품질 검사
BIOS/OS 설치를 판단 → 상황이 바뀌면? → ① 맞춤형 AI
키보드를 입력해야 한다 → HID가 안 먹으면? → ① 맞춤형 AI
매 동작마다 기록한다 → 데이터는? → ④ 파이프라인
외부 없이 동작해야 → 보안은? → ⑥ Edge + 보안
그리고 \;또 하나의 난제를 식별했다:
★ 이 수작업을 자동화하려면 공정 자체를 새로 정의해야 한다 → ⑦ 공정 창출
스마트 팩토리의 본질: 기존 수작업을 그대로 자동화하는 것이 아니라, 자동화에 맞게 \;공정 자체를 재설계하는 것. "\;로봇이 USB를 꽂을 수 없다"\;는 한계에서 "\;전자 스위칭으로 물리 삽입 자체를 없앨 수 있지 않을까?"\;라는 \;공정 재설계 아이디어가 나왔다 (TS3USB30, 구상 단계). DigiKey가 말하는 Smart Factory 4.0의 핵심도 같다 &mdash\; \;자동화가 공정을 바꾸고, 바뀐 공정이 새로운 데이터를 만든다.
2. Phase 1: 물리 만능주의의 실패
"\;로봇이 전부 물리적으로 해야지"\; USB를 꽂고, 키보드를 치고, 화면을 읽고...
시도와 현실
| 시도 | 결과 | 원인 |
|---|---|---|
| USB를 로봇으로 물리 삽입 | Visual Servoing 0.07mm 수렴 성공! 근데... 삽입하려니까 밀린다 | 삽입력 필요, 백래시 |
| 카메라로 모니터 화면 촬영 | ESP32-CAM &rarr\; OCR 60%, LLM 매번 호출 &rarr\; 비용 폭발 | 반사광 + 워핑 |
$30 서보 로봇의 한계
| 항목 | 현실 |
|---|---|
| 필요한 정밀도 | ±\;0.5mm |
| 기어 백래시 | ~2mm |
| 필요한 삽입력 | ~5N |
| 힘 제어 | 불가능 |
사고: 서보 모터 2회 고장 &mdash\; 장애 대응의 진화
1차 고장: IK 없이 고생
연속 고부하 &rarr\; 서보 과열 &rarr\; \;배선 피복 녹음 \;&rarr\; 기어 변형. 교체 후 캘리브레이션 절차가 없어 수작업으로 각도를 하나씩 맞추느라 \;수 일 \;소요.
2차 고장: IK + MCP로 빠른 복구
같은 증상 재발. 하지만 이번에는:
- IK 캘리브레이션 절차가 \;코드로 정립되어 있었고
- MCP 서버(
amfx-ik-control)로 검증 자동화 - 서보혼 방향 역전(direction +1&rarr\;-1) 발견 &rarr\; 카메라 3대로 즉시 확인 &rarr\; \;수 시간 \;복구
모든 과정이 라벨링된 데이터로 저장
서보 교체, 캘리브레이션 시행착오, FK/IK 검증 결과 &mdash\; \;같은 DB row에 센서값+관절각도+TCP 좌표+작업 컨텍스트를 함께 기록. 고장 &rarr\; 교체 &rarr\; 복구 과정 자체가 이상징후 탐지 모델의 학습 데이터가 된다.
"\;고장이 나야 고장을 예방할 수 있다"\; \;&mdash\; 1차는 고생, 2차는 절차화, 다음은 자동화.
IK(역기구학)란 무엇이고, 왜 이렇게 어려운가
**IK(Inverse Kinematics, 역기구학)**란 "\;로봇 끝(TCP)을 원하는 위치에 갖다 놓으려면 각 관절을 몇 도로 꺾어야 하는가"\;를 계산하는 것이다.
목표: TCP를 (200, 0, 275)mm에 놓아라
→ base를 몇 도? shoulder를 몇 도? elbow를 몇 도? wrist를 몇 도?
→ 이 역방향 계산이 IK
산업용 로봇은 \;엔코더(각도 센서)가 내장되어 있어 현재 각도를 정확히 안다. 그리고 제조사가 \;정밀 캘리브레이션 데이터를 제공한다. 하지만 $30 서보 로봇에는:
| 산업용 로봇 | $30 서보 로봇 |
|---|---|
| 엔코더 내장 (0.01°\; 정밀도) | 엔코더 없음 \;(PWM 신호만) |
| 제조사 캘리브레이션 데이터 | 데이터시트 없음 |
| 링크 길이 정밀 가공 | 수작업 측정 \;(버니어 캘리퍼스) |
| 감속기 백래시 <\; 0.1mm | 기어 백래시 ~2mm |
| 서보혼 정밀 결합 | 서보혼 방향이 교체마다 바뀜 |
따라서 IK를 동작시키려면 \;모든 파라미터를 직접 측정하고, 카메라로 검증하고, 시행착오로 맞춰야 \;한다. 이 과정이 IK 캘리브레이션이다.
IK 캘리브레이션에 필요한 절차
1. 링크 길이 측정 ? 각 관절 축 중심 사이의 물리 거리
2. 서보 홈 위치 측정 ? 각 관절을 알려진 자세(수평/수직)에 놓고 서보 각도 기록
3. 방향(direction) 결정 ? 서보 각도를 올렸을 때 팔이 어느 쪽으로 움직이는지 (+1/-1)
4. FK(순기구학) 수식 검증 ? 서보 각도 → TCP 좌표 계산이 실제와 맞는지 확인
5. IK(역기구학) 검증 ? TCP 좌표 → 서보 각도 계산 후 실제 이동, 오차 측정
6. 반복 ? 오차가 허용 범위 안에 들어올 때까지 파라미터 조정
이 절차를 \;서보 교체할 때마다 \;다시 해야 한다. 그래서 1차 고장 때는 수 일이 걸렸고, 2차에는 절차를 코드화+MCP 서버화하여 수 시간으로 단축했다.
IK 개발 &mdash\; 수십 회의 시행착오, AI 분산 협업
$30 서보 로봇에는 엔코더도 없고, 데이터시트도 없다. \;모든 것을 직접 측정하고 시행착오로 캘리브레이션했다.
IK 작업은 Claude 에이전트(오케스트레이션)와 \;Codex 5.3(기구학 전문 연산)에 분산하여 전문성을 강화했다. Codex 5.3에게 3대 카메라(Top View, Side View, Eye-in-Hand)의 실시간 이미지와 ArUco 마커 좌표를 제공하고, \;카메라 이미지 기반의 마커 검증 IK 방식을 함께 고안했다.
기하학적 IK Solver 설계
6축이지만 FK/IK는 4축(base, shoulder, elbow, wrist_pitch)으로 풀었다. J5(wrist_roll)는 방향만, J6(gripper)는 개폐만 담당.
물리 각도 = home_physical + (servo_angle - servo_home) × direction
이 한 줄 수식의 4개 파라미터(servo_home, home_physical, direction, link_length)를 찾는 데 \;4일이 걸렸다.
ArUco 마커 기반 IK 캘리브레이션 방식
엔코더 없이 IK 정확도를 검증하려면 \;외부 관측이 필수다. OpenCV ArUco (DICT_4X4_50) 마커 시스템을 설계했다:
| 마커 ID | 크기 | 부착 위치 | 용도 |
|---|---|---|---|
| ID 0 | 3cm | 로봇 TCP (펜 끝) | TCP 실측 위치 추적 |
| ID 1~4 | 4cm | 작업대 고정 (알려진 좌표) | Homography 계산 (pixel&rarr\;mm 변환) |
| ID 5 | 3cm | 타겟 (버튼 위치 등) | 작업 목표 위치 |
IK 검증 절차:
1. 고정 마커 4개 감지 → Homography 행렬 계산 (pixel→world mm)
ID 1: (150, +100)mm ID 2: (150, -100)mm
ID 3: (250, 0)mm ID 4: (100, 0)mm
2. 로봇을 IK 목표 위치로 이동
3. Top View 카메라로 TCP 마커(ID 0) 촬영
→ pixel 좌표 → Homography 변환 → world 좌표 (mm)
4. Side View 카메라로 높이(z) 검증
→ 수직 방향 확인
5. FK 예측 좌표 vs 카메라 관측 좌표 비교
→ 오차 <\; 0.3mm이면 PASS
6. Eye-in-Hand 카메라로 근접 작업 시 미세 검증
이 방식으로 \;엔코더 없이도 카메라+마커로 FK/IK를 정량 검증할 수 있었다.
캘리브레이션 과정
| 단계 | 방법 | 시행착오 |
|---|---|---|
| 링크 길이 | 버니어 캘리퍼스로 직접 측정 | 3회 재측정 (축 중심점 찾기 어려움) |
| 서보 홈 위치 | 서보를 물리적으로 수평/수직에 놓고 각도 기록 | 관절마다 기준이 다름 |
| 방향(direction) | 서보 +10°\; &rarr\; 카메라로 팔이 올라갔는지 내려갔는지 확인 | 엘보우 direction=-1 \;(서보&uarr\;&rarr\;팔 앞으로) 발견에만 반나절 |
| home_physical | vertical_90 제약조건 (어깨=90°\;일 때 팔이 수직) | 수식 역산으로 -67.75°\; 도출 |
엘보우 서보혼 재장착 &mdash\; 전체 재캘리브레이션
서보 과열 사고 후 기어 변형 &rarr\; 서보 교체 &rarr\; \;서보혼 장착 각도가 바뀜 \;&rarr\; FK 전체 틀어짐.
교체 전: servo_home = 72.75, direction = +1
교체 후: servo_home = 87.25, direction = -1
변환식: new_servo = 160 - old_servo
direction이 반전된 것을 발견하기까지 2시간. \;카메라 top_view + side_view로 서보 각도를 +10°\; 올려보고, 팔이 어느 쪽으로 움직이는지 반복 확인. Codex 5.3이 카메라 이미지 3장(top, side, eye-in-hand)을 동시 분석하여 direction 역전 현상을 수치적으로 확인했다.
IK 검증 &mdash\; 5개 포즈 + Round-Trip
| 포즈 | 목표 TCP (mm) | 실제 오차 | 결과 |
|---|---|---|---|
| Forward High | (200, 0, 275) | 0.2mm | PASS |
| Left High | (150, 100, 275) | 0.3mm | PASS |
| Right High | (150, -100, 275) | 0.3mm | PASS (Left와 완벽 대칭) |
| Center Lower | (180, 0, 200) | 0.2mm | PASS |
| Forward-Left Low | (200, 80, 200) | 0.2mm | PASS |
| Round-Trip Home | 시작&rarr\;5포즈&rarr\;복귀 | 0.0mm | PASS (완벽 일치) |
검증 시 \;3대 카메라로 동시 촬영: Top View(XY 평면), Side View(XZ 평면), Eye-in-Hand(근접 확인). 각 포즈에서 ArUco 마커 감지 &rarr\; Homography 변환으로 FK 예측 vs 실측 비교.
MCP 서버 &mdash\; Single Source of Truth
포즈와 속도를 여러 곳에서 정의하면 \;불일치로 충돌 사고가 난다. MCP 서버 코드가 유일한 진실 소스:
amfx-power-button: 전원 버튼 IK 포즈 + 속도 + 안전 가드amfx-ik-control: 일반 IK 이동 + 직선 삽입 + TCP 좌표 가드- TCP x guard: z <\; 220mm일 때 x <\; 150mm 강제 &mdash\; \;로봇 TCP가 Target PC 본체와 충돌하는 것을 방지
- 절대 금지: 직접 curl로 로봇에 명령 &rarr\; MCP 가드 우회 위험
Codex 5.3이 MCP 도구를 설계하여, 복잡한 IK 시퀀스를 단순한 도구 호출로 추상화했다:
MCP Tool: short_key → 전원 켜기 (LIFT→APPROACH→PRESS 0.05s→RETRACT→PARK)
MCP Tool: long_key → 강제 종료 (LIFT→APPROACH→PRESS 5.0s→RETRACT→PARK)
MCP Tool: move_tcp → IK 좌표 이동 (안전 가드 포함)
AI 에이전트는 IK 수식이나 서보 각도를 몰라도 \;short_key \;한 번이면 전원 버튼을 누를 수 있다. \;IK의 복잡성을 MCP 도구 뒤에 숨겨서, 누구든(Claude든, Codex든, 사람이든) 안전하게 로봇을 제어할 수 있게 만들었다.
$30 서보 로봇으로 \;0.2mm FK/IK 정밀도를 달성한 것은 엔코더가 아니라 \;카메라 3대 + ArUco 마커 + 시행착오 캘리브레이션의 결과다. IK 전문 작업은 Codex 5.3에 분산하여, Claude(오케스트레이션) + Codex(기구학 연산) 협업 구조로 효율을 높였다.
3. 삽질 &rarr\; 깨달음: 5단계 진화
물리 만능 → 전자 스위칭(구상) → 센싱 품질 → 에이전트 효율 → 최적 분리
"로봇이 다 해야지" TS3USB30 $4 제안 HDMI 캡처 $10 ReAct→Plan-Execute 물리: 전원 버튼만
→ 서보가 탔다 → USB 물리 삽입 한계 → OCR 60%→100% → LLM 호출 30x↓ 나머지: 전부 전자적
처음 계획 &rarr\; 실제 구현 &rarr\; 다음 아이디어
| 작업 | 처음 계획 | 실제 구현 | 다음 아이디어 |
|---|---|---|---|
| USB | 로봇이 물리 삽입 | 사람이 수동 1회 삽입 \;(백래시+삽입력 한계) | TS3USB30 전자 스위칭 ($4, 구상) |
| 키보드 | 로봇이 물리 타이핑 | Pico HID ($4) \;&mdash\; UART&rarr\;USB HID 에뮬레이션 | 구현 완료, 유지 |
| 화면 읽기 | 카메라로 모니터 촬영 | ESP32-CAM \;WiFi 캡처 (OCR&rarr\;AI 판독) | HDMI 캡처보드 ($10) 디지털 직접 수신 |
| 전원 | 로봇이 본체 버튼 누름 | 1mm 저압 스위치 \;+ IK 프레스 (MCP \;short_key) |
구현 완료, 유지 |
깨달음: "\;무엇을 물리적으로 할 것인가"\;의 경계를 찾는 것이 제조 라인 설계의 본질
4. 실제로 해본 것 &mdash\; 2가지 물리 작업
사례 1: 전원 버튼 프레스
$30 서보 로봇으로 PC 본체 전원 버튼을 누른다.
문제: 본체 버튼 압력 >\; 서보 출력 → 누를 수 없음
해결: 1mm 저압 택트 스위치로 교체 → "힘"이 아니라 "정확도"로 전환
결과: MCP short_key 한 번이면 전원 ON (IK 0.2mm 정밀도)
IK 캘리브레이션 &rarr\; MCP 도구화 &rarr\; 반복 가능한 자동 전원 제어 완성.
사례 2: BIOS 설정 &rarr\; Ubuntu 설치 전 과정 자율 수행
전원이 켜진 후, ESP32-CAM으로 모니터 화면을 촬영하고, Claude Agent가 화면을 해석해서 Pico HID로 키보드를 조작한다.
ESP32-CAM (WiFi) → 화면 캡처 (2048×1536)
↓
Claude Agent → 화면 상태 분류 + OCR → 다음 키 결정
↓
Jetson → HTTP → RPI4 → UART → Pico → USB HID → Target PC
↓
BIOS POST → F8 Boot Menu → USB 선택 → GRUB → Ubuntu Installer
→ 언어/키보드/네트워크/파티션/사용자 설정 → 설치 완료 → 재부팅 → 로그인
전 과정을 Claude Agent가 1회 완전 자율 수행에 성공했다.
| 단계 | AI가 한 일 |
|---|---|
| BIOS POST | 화면에서 "\;Press F8"\; 인식 &rarr\; F8 키 전송 |
| Boot Menu | USB 드라이브 항목 OCR &rarr\; 방향키+Enter |
| Ubuntu Installer | 각 화면(언어, 파티션, 사용자 등)마다 판단 &rarr\; 입력 |
| 설치 중 | 진행률 모니터링 &rarr\; 10~20분 대기 |
| 완료 후 | "\;Restart Now"\; 인식 &rarr\; 클릭 &rarr\; 재부팅 &rarr\; 로그인 |
예상 못한 삽질: 보안과 절전
자율 설치 과정에서 OS/하드웨어 레벨의 예상 못한 장벽에 부딪혔다:
| 문제 | 증상 | 해결 |
|---|---|---|
| Ubuntu 절전 | 설치 중 10분 무입력 &rarr\; 화면 꺼짐 &rarr\; ESP32-CAM 검은 화면 &rarr\; Agent 판단 불가 | 설치 전 \;gsettings \;절전 해제, 또는 주기적 키 입력으로 깨우기 |
| Ubuntu 잠금화면 | 재부팅 후 자동 잠금 &rarr\; 비밀번호 입력 필요 &rarr\; Agent가 로그인 화면 인식 필요 | 화면 상태 분류에 \;login_screen \;추가, 자동 비밀번호 입력 |
| Pico USB 인식 | Ubuntu가 Pico를 "\;새 장치"\;로 인식 &rarr\; 팝업 &rarr\; 설치 흐름 방해 | Pico를 키보드+마우스로만 인식시키는 CircuitPython 설정 |
| BIOS 보안 부팅 | Secure Boot 활성화 &rarr\; USB 부팅 거부 | BIOS에서 Secure Boot 비활성화 단계 추가 |
| SSD 고장 발견 | 설치 반복 중 디스크 에러 &rarr\; 파티션 실패 &rarr\; 설치 불가 | AI가 에러 화면 판독 &rarr\; SSD 불량 판단 &rarr\; \;물리 SSD 교체 \;(128GB) |
SSD 고장은 의도한 시나리오가 아니었다. 자율 설치를 반복하다가 \;우연히 디스크 에러를 만났고, Agent가 화면 에러 메시지를 읽어 SSD 불량을 판단했다. 결과적으로 "\;이상징후 탐지 &rarr\; 원인 진단 &rarr\; 부품 교체"\;라는 \;실제 제조 현장의 장애 대응 시나리오를 경험하게 되었다.
소프트웨어만 짜면 될 줄 알았는데, \;OS의 보안/절전 정책이 자율 제어의 숨은 적이었고, SSD 고장까지 만났다.
5. 그래서 뭘 만들었나 &mdash\; 핵심 숫자
| 지표 | 수치 | 설명 |
|---|---|---|
| 0.2mm | FK/IK 정밀도 | 6축 서보 로봇 |
| 0.07mm | Visual Servoing 수렴 | ArUco + Homography |
| 88x | Edge vs Cloud 속도 | 84ms vs 7,435ms |
| 7/7 | 난제 해결 | 6대 + 공정 창출 |
시스템 아키텍처 &mdash\; 통신 구조
┌──────────────────────────────────────────────────────────────────────┐
│ Jetson Xavier NX (AI Hub, :8000) │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌──────────────┐ │
│ │ Claude │ │ YOLO v8 │ │ Visual │ │ Camera │ │
│ │ Agent │ │ TensorRT │ │ Servoing │ │ Manager │ │
│ └─────┬──────┘ └────────────┘ └──────┬─────┘ └──┬───┬───┬───┘ │
│ │ │ │ │ │ │
│ │ HTTP REST │ HTTP POST │ │ │ │
├────────┼────────────────────────────────┼────────────┼───┼───┼──────┤
│ ▼ ▼ │ │ │ │
│ ┌─────────────────────────────────────────────┐ │ │ │ │
│ │ Raspberry Pi 4 (Control Hub, :5000) │ │ │ │ │
│ │ │ │ │ │ │
│ │ Flask API ←── HTTP REST ──→ Jetson │ │ │ │ │
│ │ │ │ │ │ │ │
│ │ ├── I2C ──→ PCA9685 ──→ MG996R ×6 (로봇) │ │ │ │ │
│ │ ├── I2C ──→ INA219 (전류 센서, addr 0x41) │ │ │ │ │
│ │ └── UART /dev/ttyAMA0 @ 115200 │ │ │ │ │
│ │ │ │ │ │ │ │
│ │ ▼ │ │ │ │ │
│ │ Pico (CircuitPython) │ │ │ │ │
│ │ │ USB HID │ │ │ │ │
│ │ ▼ │ │ │ │ │
│ │ Target PC (키보드/마우스) │ │ │ │ │
│ └─────────────────────────────────────────────┘ │ │ │ │
│ │ │ │ │
│ ┌─── USB 카메라 ────────────────────────────────────┘ │ │ │
│ │ Top View (/dev/video3, 640×480) │ │ │
│ │ Side View (/dev/video1, 640×480, 180° 회전) ────────┘ │ │
│ │ Eye-in-Hand (/dev/video5 또는 RPI4 HTTP) ──────────────┘ │
│ └──────────────────────────────────────────────────────────────┘ │
│ │
│ ┌─── WiFi ───────────────────────────────────────────────────┐ │
│ │ ESP32-CAM (192.168.0.50) ── HTTP GET /capture/hires │ │
│ │ → Target PC 모니터 화면 캡처 (2048×1536) │ │
│ └────────────────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────────────────┘
통신 프로토콜 요약
| 경로 | 프로토콜 | 용도 |
|---|---|---|
| Jetson &harr\; RPI4 | HTTP REST (Ethernet) | 로봇 제어, IK, HID 중계 |
| RPI4 &harr\; PCA9685 | I2C (addr 0x40) | 6축 서보 PWM |
| RPI4 &harr\; INA219 | I2C (addr 0x41) | 전류 모니터링 |
| RPI4 &harr\; Pico | UART 115200 (GPIO14/15&rarr\;GP0/GP1) | HID 키보드/마우스 명령 |
| Pico &rarr\; Target PC | USB HID | 물리 키보드/마우스 에뮬레이션 |
| Jetson &larr\; ESP32-CAM | HTTP GET (WiFi) | 화면 캡처 (2초 간격) |
| Jetson &larr\; USB 카메라 ×\;3 | USB (V4L2) | Top/Side/Eye-in-Hand 영상 |
배포 &mdash\; OTA 없이 실시간 교체
OTA 인프라 대신 \;RPI4가 직접 제어 허브이므로 scp/ssh로 실시간 서버+코드 교체가 가능하다:
# Backend 코드 → RPI4 실시간 배포
scp -r backend/ rpi4:/home/arm/amfx/
ssh rpi4 "cd /home/arm/amfx &\;&\; fuser -k 5000/tcp\; nohup python run.py \--production &\;"
# AI 코드 → Jetson 실시간 배포
scp -r jetson_ai/ jetson:/home/nvidia/amfx/
ssh jetson "cd /home/nvidia/amfx &\;&\; fuser -k 8000/tcp\; nohup uvicorn main:app \--host 0.0.0.0 \--port 8000 &\;"
- PDCA 반복 시 코드 수정 &rarr\; 즉시 배포 &rarr\; 즉시 검증 \;(수 분)
- 레거시: OTA 시스템 구축 + 펌웨어 빌드 + 배포 검증 = \;수 일
구성 요약
- 4대 카메라: Top View + Side View + Eye-in-Hand + ESP32-CAM (화면 캡처)
- 2대 컴퓨터: Jetson (AI) + RPI4 (제어)
- 1대 로봇: 6축 MG996R (FK/IK)
- 1대 Pico: USB HID (키보드/마우스 에뮬레이션)
실제 시연 &mdash\; 물리적으로 무엇을 했나
Claude 에이전트로 전원 버튼&rarr\;Ubuntu 설치 전 과정을 1회 완전 수행했다.
물리 작업 1: 전원 버튼 프레스 (저압 스위치)
$30 서보 로봇은 데스크탑 PC 본체의 전원 버튼을 누를 만한 \;압력이 부족했다. 따라서 \;1mm 저압 택트 스위치로 교체하여, 정밀도 기반의 반복 작업으로 전환했다.
동작 시퀀스:
1. LIFT 포즈 이동 (안전 높이)
2. APPROACH 포즈 이동 (스위치 바로 위)
3. PRESS: shoulder 190→160 (speed=120) ? TCP가 스위치를 누름
4. HOLD: short=0.05s (전원 켜기) / long=5.0s (강제 종료)
5. RETRACT: shoulder 160→190 (복귀)
6. PARK 포즈 + emergency_stop
- 왜 저압 스위치인가: 본체 버튼 압력 >\; 서보 출력 &rarr\; 힘 제어 불가 &rarr\; "\;힘이 아니라 정확도"\;로 전환
- IK 정밀도: 0.2mm (기하학적 IK, 엔코더 없이 달성)
- TCP x guard: z <\; 220mm에서 x <\; 150mm 강제 &mdash\; Target PC 본체와의 충돌 방지
- MCP 서버: 포즈/속도의 유일한 진실 소스, 외부 접근 차단
버튼 프레스 = 이상탐지용 정상 데이터 수집
버튼 프레스는 단순 동작이 아니라 \;이상탐지를 위한 정상 데이터 라벨링 작업이기도 하다. 매 프레스마다 같은 DB row에 기록:
{timestamp, 전류(INA219), 전압, joint_angles[6], TCP_xyz, action:"short_key", result:"success"}
이 데이터가 누적되면 "\;정상 버튼 프레스"\;의 전류/전압/관절각도 패턴이 형성되고, 이상값(서보 나사 풀림, 기어 마모, 부하 증가 등)을 탐지하는 기준선이 된다.
실제 사례 (오늘): 서보 모터 고정 나사가 풀어져 좌표가 틀어짐 &rarr\; 누적된 정상 데이터와 비교하면 관절각도 편차로 즉시 감지 가능 &rarr\; 나사 재체결 + IK 재조정으로 복구. 이런 장애까지 포함한 데이터가 이상탐지 모델의 학습 데이터가 된다.
작업 = 수집: 별도의 데이터 수집 공정 없이, 반복 작업 자체가 이상탐지 모델의 정상 기준선을 만든다.
물리 작업 2: USB 삽입 (수동) + Ubuntu 자동 설치
USB 물리 삽입은 \;서보 백래시 ~2mm + 삽입력 부족으로 로봇 자율 수행이 불가능했다. 따라서 \;USB는 사람이 1회 수동 삽입하고, 이후 전원 버튼&rarr\;BIOS&rarr\;Ubuntu 설치 전 과정을 Claude 에이전트가 자율 수행한다.
이 한계 인식이 TS3USB30 전자 스위칭 구상으로 이어졌다 &mdash\; "\;물리를 줄이고 전자로 대체"\;
전원 버튼을 눌러 PC가 켜지면, Claude 에이전트가 \;ESP32-CAM으로 화면을 캡처하고 \;Pico HID로 키보드/마우스를 조작하여 Ubuntu 설치 전 과정을 자율 수행한다.
실행 체인:
Jetson (Claude Agent) ←HTTP→ ESP32-CAM (화면 캡처)
│
│ HTTP (POST /api/v1/hid/key, /type, /combo)
▼
RPI4 (HID relay) ←UART→ Pico ←USB HID→ Target PC
| 단계 | 수행 내용 | AI 판단 |
|---|---|---|
| BIOS POST | F8 &rarr\; Boot Menu 진입 | 화면 상태 분류 &rarr\; 키 결정 |
| Boot Menu | USB 드라이브 선택 | OCR로 항목 읽기 &rarr\; 선택 |
| GRUB | "\;Install Ubuntu"\; 선택 | 화면 인식 &rarr\; Enter |
| Installer | 언어, 키보드, 네트워크, 파티션, 사용자 설정 | 각 화면별 판단 &rarr\; 입력 |
| 설치 진행 | 10~20분 대기 | 진행률 모니터링 |
| 완료 | "\;Restart Now"\; 클릭 | 완료 화면 인식 &rarr\; 재시작 |
| First Boot | 로그인 &rarr\; 터미널 오픈 &rarr\; 초기 설정 | 데스크탑 인식 &rarr\; 명령 입력 |
1회 전체 수행 후, 이 수행 결과가 Edge MLOps의 입력 데이터가 된다.
6. 7대 난제 &mdash\; 어떻게 해결했나
난제를 "\;선택"\;한 것이 아니다. 공정을 만들었더니 \;7개 전부 자연 발생했고, 삽질하면서 해결했다.
난제 매핑: 대회 문제 &rarr\; 내 문제
| # | 난제 | 대회 문제 정의 | AMFX에서 만난 문제 |
|---|---|---|---|
| ① | 맞춤형 AI | 공정 상태별 다른 판단이 필요한데, 범용 AI로는 느리고 비싸다 | 화면 상태별 다른 키 입력 필요, Cloud LLM 7초/판단 |
| ② | 이상징후 탐지 | 장비 고장을 사전에 감지하여 가동 중단을 막아야 한다 | 서보 과열 &rarr\; 기어 변형, 접촉 시 TCP 밀림 |
| ③ | 품질 검사 | 작업 결과가 정상인지 자동으로 판정해야 한다 | 버튼 눌림 성공/실패 판정, 화면 전환 확인 |
| ④ | 데이터 파이프라인 | 공정 데이터를 AI가 학습할 수 있는 형태로 수집해야 한다 | 전류만 쌓으니 맥락 없어 쓸 수 없었음 |
| ⑤ | 공정 제어 | 로봇이 정확한 위치에 반복적으로 도달해야 한다 | 서보 백래시 ~2mm, USB 삽입 불가 |
| ⑥ | 보안 + Edge | 폐쇄망 제조 환경에서 인터넷 없이 AI가 동작해야 한다 | Cloud 100% 의존 &rarr\; 인터넷 없으면 멈춤 |
| ⑦ | 공정 창출 | 수작업이라 공정으로 정의조차 안 된 80%의 제조 영역 | 물리 삽입 불가 &rarr\; 공정 자체를 재정의해야 했음 |
어떻게 해결했나
| # | 난제 | 삽질 | 해결 | 증거 |
|---|---|---|---|---|
| ① | 맞춤형 AI | Cloud LLM 매번 호출 &rarr\; 7초/판단, 비용 폭발 | Cloud&rarr\;Edge 점진 이관, DecisionTree 23규칙 | 84ms, 88x&uarr\; |
| ② | 이상징후 탐지 | 엘보우 서보 과열 &rarr\; 기어 변형 사고 | TorqueGuard: IK 시점에 좌표 기반 부하 사전 추정 | Score 75&rarr\;차단 |
| ③ | 품질 검사 | YOLO 학습 데이터 없음, ESP32-CAM OCR 60% | ArUco 위치검증 + HDMI 캡처 OCR + AI 화면 판독 | 센서 퓨전 |
| ④ | 데이터 파이프라인 | 전류 데이터만 쌓으니 관절 맥락 없어 쓸 수 없었음 | 같은 row에 센서+관절각도+TCP 좌표 = 자동 라벨링 | 작업=수집 |
| ⑤ | 공정 제어 | 서보 백래시 ~2mm, 그리퍼 떨림, USB 삽입 불가 | 기하학적 IK 0.2mm + Visual Servoing 폐루프 0.07mm | 0.2mm 정밀 |
| ⑥ | 보안 + Edge | 클라우드 100% 의존 &rarr\; 인터넷 없으면 멈춤 | Edge 규칙 90% + LLM fallback 10% + 온프레미스 DB | 오프라인 OK |
| ⑦ | 공정 창출 | 물리 삽입 불가 &rarr\; 공정 자체를 재정의해야 했음 | 전자 스위칭(구상) + HDMI 캡처 &rarr\; 물리&rarr\;전자 공정 전환 설계 | 바이브 제조 |
모든 난제의 공통 패턴: \;더 좋은 기술을 쌓아서 \;해결한 게 아니라, \;문제를 다시 정의해서 \;해결했다.
7. Edge MLOps &mdash\; Cloud가 가르치고, Edge가 실행
왜 Edge가 필요한가?
이 시스템의 강점은 \;전원 버튼 &rarr\; BIOS 설정 &rarr\; OS 설치까지 전 과정을 AI가 자율 수행할 수 있다는 것이다. 하지만 Cloud LLM에 100% 의존하면 \;인터넷 없이 동작 불가, 호출당 수 초 지연, API 비용 누적 \;문제가 있다.
전 과정 중 \;BIOS 부팅 순서 변경(어떤 디스크로 부팅할지 선택)을 Edge MLOps PoC 대상으로 선택했다. 이유:
- BIOS는 네트워크 없는 환경 &mdash\; Cloud 호출 자체가 불가능한 상황이 실제로 발생
- 화면 상태가 명확히 구분됨 &mdash\; 규칙 기반 Edge 모델로 대체 가능성이 높음
- 전체 공정의 앞단 &mdash\; 여기가 Edge로 동작하면 나머지도 같은 패턴으로 확장 가능
시간 제약으로 전체 공정이 아닌 \;BIOS 부팅 순서 변경을 PoC로 수행했다. Cloud LLM으로 먼저 전 과정을 검증하고, 이 중 한 구간을 Edge로 전환하는 과정을 증명했다.
출발점: Claude Agent로 전 과정 1회 물리 수행
처음부터 Tiny LLM? \;성능 부족 &rarr\; 프레임워크 자체 검증 불가.
그래서 \;먼저 고성능 Cloud LLM(Claude Opus)으로 전원 버튼&rarr\;Ubuntu 설치 전 과정을 1회 완전 수행했다. 이 1회 수행 데이터가 Edge 경량 모델의 학습 데이터가 된다.
1회 수행 시 자동 수집되는 메타데이터:
├── 화면 캡처 (ESP32-CAM JPEG) → 화면 상태 분류 학습용
├── LLM 판단 (action, reasoning) → 규칙 엔진 추출용
├── 화면 상태 (screen_state) → DecisionTree 학습용
├── HID 실행 결과 (success/fail) → 보상 신호
└── Phase 전이 기록 → 상태 머신 설계용
우리의 접근: \;Cloud LLM으로 먼저 증명 &rarr\; 수행 결과 메타데이터화 &rarr\; Edge 모델로 점진 이관
4-Phase 전환
1. Prototype 2. Shadow 3. Edge Primary 4. Edge Only
Cloud LLM 100% → Edge 병렬 실행 → Edge 먼저 시도 → Cloud 호출 0%
공정 검증 자동 라벨링 LLM은 fallback 84ms, 오프라인
LLM &rarr\; Edge 대체 결과
| LLM이 하던 일 | 대체 Edge 모델 | 속도 개선 |
|---|---|---|
| 화면 상태 분류 | ScreenClassifier (heuristic) | 2,000ms &rarr\; \;5ms |
| 화면 텍스트 읽기 | PaddleOCR + TensorRT | 2,000ms &rarr\; \;30ms |
| 행동 결정 | DecisionTree (23 규칙) | 2,000ms &rarr\; \;<\;1ms |
| 센서 이상 감지 | EdgeAnomalyDetector | threshold &rarr\; \;ML |
| 복잡한 판단/복구 | LLM 유지 (10%) | fallback only |
= **숙련공(LLM)**이 공정을 만들고 &rarr\; **자동화 라인(Edge)**이 반복 실행하는 산업 최적화 패턴
보안: 제조 데이터가 외부로 나가지 않는 구조
① 데이터 유출 차단 &mdash\; Edge 전환
이 시스템의 가장 큰 보안 위협은 Cloud LLM 호출이다. 화면 캡처, 공정 데이터, AI 판단 요청이 외부 서버를 경유한다.
| \; | Cloud LLM 단계 | Edge 전환 후 |
|---|---|---|
| 화면 데이터 | 외부 API 서버로 전송 | Jetson 로컬 처리 |
| 판단 로직 | 외부 서버에서 실행 | DecisionTree 로컬 실행 |
| 네트워크 | 인터넷 필수 | 오프라인 동작 |
| 데이터 유출 | 가능성 있음 | 물리적 불가 |
Edge 전환 후 Cloud 호출 0% &rarr\; 모든 데이터가 로컬 장비 안에서 처리된다.
대기업은 이미 \;Enterprise LLM을 폐쇄망에 배포하여 Cloud 단계에서도 보안을 유지한다. 이 프로젝트의 Cloud&rarr\;Edge 전환 패턴은 Enterprise LLM 환경에서도 동일하게 적용된다: 폐쇄망 LLM으로 검증 &rarr\; Edge 모델로 이관 &rarr\; 최종적으로 LLM 호출 없이 자율 동작.
② 장비 접근 통제 &mdash\; SSH 키 인증
장비 간 통신은 SSH 키 기반 인증만 허용. 비밀번호 로그인 비활성화.
- RPI4, Jetson, Target PC 모두 \;
id_ed25519\;키 인증 - 배포(scp), 원격 제어(ssh), 로그 수집 전부 키 기반
- 실제로 RPI4 비밀번호 분실 &rarr\; 키 인증만으로 운영 중
③ 물리적 격리 &mdash\; HID 단방향 통신
Pico HID는 \;키보드/마우스 출력만 \;가능하다. Target PC의 데이터를 읽을 수 없다.
Pico → USB HID → Target PC: 키 입력, 마우스 이동 (출력만)
Pico ← Target PC: 전원 공급뿐 (데이터 수신 불가)
제어 시스템이 Target PC의 디스크, 네트워크, 메모리에 접근할 경로 자체가 없다.
8. PDCA 7회 &mdash\; BIOS Boot Priority 자율 변경
Edge 규칙 엔진으로 \;BIOS 부팅 순서를 자율 변경. 양방향(SSD&harr\;USB) 22 steps, Cloud 호출 0회.
반복 결과
| 회차 | 정확도 | 핵심 변경 |
|---|---|---|
| 1 | 0% | 초기 규칙만 |
| 2 | 57% | bios_popup 상태 추가 |
| 3 | 86% | 카운터 기반 규칙 |
| 4 | 100% | 스텝 카운터 완성 |
| 5 | 57% \;&larr\; 회귀! | OCR 추가 &rarr\; 기존 기능 깨뜨림 |
| 6 | 86% | OCR 허위양성 제거 |
| 7 | 100% | 카운터+OCR 안정 |
5회차 &mdash\; 회귀의 교훈
"\;기능 추가(OCR)가 오히려 정확도를 깨뜨렸다"\; &rarr\; \;더 많은 기술 &ne\; 더 좋은 결과 \;&rarr\; 기존에 되던 것부터 지키고, 점진적으로 추가
최종 결과
| 방향 | 대상 | 단계 수 | Edge 자율 | Cloud 호출 |
|---|---|---|---|---|
| SSD&rarr\;USB | Kingston USB (Ventoy) | 22 steps | 100% | 0회 |
| USB&rarr\;SSD | SSD (Ubuntu) | 22 steps | 100% | 0회 |
7회 PDCA를 몇 시간 만에 돌렸다. 레거시 생산기술팀이라면? \;수주~수개월.
9. Q1 설계 &rarr\; Q3 실전: 답이 바뀌었다
Q1에서 설계한 답은 \;논문에서 나온 답이었고, Q3에서 재정의된 답은 \;로봇이 고장나고 서보가 타면서 나온 답입니다.
| 질문 | Q1 설계 (1월) | Q3 실전 (3월) | 패턴 |
|---|---|---|---|
| 이상을 미리 알 수 있나? | ML 예측 모델 | TorqueGuard 좌표 기반 예방 | 우회 |
| 불량 검사를 AI로? | YOLO 비전 검사 | 센서 퓨전 (전류+비전+LLM) | 퓨전 |
| 숙련자 경험 표준화? | if-else 규칙 | IK 좌표 + 경험 DB + HIL | 설계 |
| 데이터를 AI가 쓸 수 있게? | InfluxDB 파이프라인 | 같은 row에 센서+동작 = 라벨링 | 단순화 |
| 보안 보장 AI? | Secure Boot 암호화 | 클라우드&harr\;로컬 전환 아키텍처 | 설계 |
Q1&rarr\;Q3 변화의 공통 패턴
| Q1 (설계) | Q3 (실전) | 패턴 |
|---|---|---|
| 복잡한 인프라 (InfluxDB, MQTT, OTA) | 단순한 구조 (SQLite, REST, scp) | 단순화 |
| 단일 기술 의존 (YOLO만, ML만) | 다중 접근 퓨전 (전류+비전+LLM) | 퓨전 |
| "\;더 좋은 도구"\; | "\;다른 접근"\; | 우회 |
10. 바이브코딩 &rarr\; 바이브 제조: AI가 PDCA를 수행할 수 있는 환경을 만들다
바이브코딩은 왜 가능한가?
바이브코딩이란 \;AI에게 의도를 말하면 AI가 코드를 생성하는 것이다. 이것이 가능한 이유는 개발 환경이 \;이미 AI-ready이기 때문이다:
| AI에게 필요한 것 | 개발 환경에서는 | 이미 있는가? |
|---|---|---|
| 눈 \;(상태 확인) | 터미널 출력, 로그, 테스트 결과 | O |
| 손 \;(실행) | 파일 읽기/쓰기, 명령어 실행 | O |
| 판단 기준 | 에러 메시지, 컴파일 결과, 테스트 통과 | O |
| 반복 구조 | 코드 수정 &rarr\; 저장 &rarr\; 실행 &rarr\; 확인 | O |
개발자가 별도로 만들 것이 없다. IDE를 열고 AI에게 말하면 된다.
제조에서는 왜 안 되는가?
제조 환경은 AI-ready가 \;아니다. AI에게 "\;이 PC에 Ubuntu 설치해"\;라고 말해도 AI가 할 수 있는 게 없다:
| AI에게 필요한 것 | 제조 환경에서는 | 있는가? |
|---|---|---|
| 눈 \;(화면 확인) | 모니터 앞에 사람이 앉아야 함 | X |
| 손 \;(키보드/마우스) | 사람이 직접 입력해야 함 | X |
| 힘 \;(물리 조작) | 버튼, USB, 케이블 = 사람 손 | X |
| 판단 기준 | 숙련자 경험, 매뉴얼 | X |
| 반복 구조 | 없음 (수작업이니까) | X |
바이브 제조 = 이 X를 O로 바꾸는 것
이 프로젝트가 한 일의 본질: \;AI가 제조 PDCA를 수행할 수 있는 제어권과 환경을 만든 것.
| AI에게 필요한 것 | AMFX가 만든 것 | 구현 |
|---|---|---|
| 눈 | ESP32-CAM + 카메라 3대 | 화면 캡처 &rarr\; OCR/LLM 분석 |
| 손 | Pico HID (키보드/마우스) | UART 명령 &rarr\; USB HID 에뮬레이션 |
| 힘 | 6축 로봇 + IK + MCP | 버튼 프레스, 물리 조작 |
| 판단 기준 | Claude Agent + 화면 분류 | 화면 상태 &rarr\; 다음 액션 결정 |
| 반복 구조 | PDCA 자동화 루프 | 실행 &rarr\; 확인 &rarr\; 수정 &rarr\; 재실행 |
| 감각 | INA219 전류 + 관절 각도 | 이상탐지 정상 데이터 수집 |
바이브코딩: 개발자 → "로그인 폼 만들어줘" → AI가 코드 PDCA
바이브 제조: 엔지니어 → "이 PC에 Ubuntu 설치해줘" → AI가 공정 PDCA
차이: 바이브코딩은 환경이 이미 있고, 바이브 제조는 \;환경 자체를 만들어야 했다. \;그 환경을 만든 것이 이 프로젝트다.
환경이 있으면 PDCA가 빨라진다
환경이 갖춰지면, AI가 사람 대신 PDCA를 수행한다:
| 생산기술 역할 | 레거시 (사람) | AMFX (AI) |
|---|---|---|
| 공정 설계 | 엔지니어 경험 + CAD, \;수 주 | 제약조건 분석 &rarr\; 플랜 생성, \;수 분 |
| 비전 셋업 | 카메라+렌즈+조명+티칭, \;수 일 | ESP32-CAM + LLM 분석, \;수 분 |
| 동작 티칭 | 티칭펜던트 수동 교시, \;수 일 | IK 좌표 API + 카메라 검증, \;수 분 |
| 불량 분석 | 숙련자 경험, \;수 시간 | AI 즉시 분석+추론, \;수 초 |
| 24/7 가동 | 3조2교대, \;인건비 | 무인 연속, \;$0 |
PDCA 1사이클이 수 주인 이유: "\;사람이 생각하고, 물리를 바꾸고, 사람이 확인"\;하기 때문. \;환경을 만들면 \;AI가 생각+실행+확인을 대체 &rarr\; 사이클이 수 분으로 줄어든다.
실제로 그랬다: PC 설치는 "\;딸깍"\;이었다
처음부터 딸깍은 아니었다. Ubuntu 설치 자동화는 \;삽질의 연속이었다:
- ESP32-CAM 화면 캡처 &rarr\; 반사광, 왜곡, OCR 60% &rarr\; 모니터 교체로 해결
- 절전 모드로 화면 꺼짐 &rarr\; Agent 판단 불가 &rarr\; 왜 멈췄는지도 모름
- Pico HID를 Ubuntu가 "\;새 장치"\;로 인식 &rarr\; 팝업이 설치 흐름 방해
- BIOS Secure Boot &rarr\; USB 부팅 거부 &rarr\; 원인 파악에 시간 소모
- SSD 고장 &rarr\; 설치 반복 중 우연히 발견
하지만 \;방향이 잡히자 딸깍이었다. \;화면 캡처&rarr\;판단&rarr\;HID 입력&rarr\;결과 확인이라는 PDCA 루프가 연결되니, 에이전트가 스스로 거의 모든 것을 해냈다. 마치 UI 기반 개발처럼 &mdash\; 프레임워크가 잡히면 나머지는 흘러간다.
에이전트: BIOS 진입 → 부팅 순서 변경 → USB 선택 → Ubuntu 설치 → 로그인 → 초기 설정
사람: (지켜봄) (확인) (지켜봄) (지켜봄) (확인) (완료 확인)
사람의 역할은 \;실행이 아니라 중간 검증으로 바뀌었다. 이것이 바이브 제조의 핵심 &mdash\; 어려운 건 모델이 아니라 \;환경을 만드는 것이다.
11. 실제 경험한 PDCA 가속 &mdash\; 4가지 사례
사례 1: 버튼 프레스 캘리브레이션
- 레거시: 지그 설계&rarr\;가공&rarr\;장착&rarr\;테스트&rarr\;수정&rarr\;재가공 = \;수일~수주
- AMFX: IK 좌표 수정&rarr\;API 호출&rarr\;카메라 확인&rarr\;재조정 = \;수 분
- 하루에 50+ iteration, Z=250mm 최적점을 당일 발견
사례 2: USB 삽입 공정 재정의
- 레거시: 정밀 지그+가이드레일+공압 실린더 설계/제작 = \;수 주
- AMFX: 서보잉 실패&rarr\;AI와 대안 탐색&rarr\;TS3USB30 전자 스위칭 구상 = \;수 분
- "\;공정이 필요한가?"\; 자체를 AI와 재검토 &rarr\; 공정을 전자적으로 재정의 \;(설계 완료, 부품 미구현)
사례 3: 화면 판독 비전 셋업
- 레거시: 비전 카메라+렌즈+조명+마운트+티칭+검증 = \;수일~수주
- AMFX: ESP32-CAM 실패&rarr\;HDMI 캡처 발견 = \;수 분
- $10으로 "\;비전 셋업"\;이라는 공정 자체가 소멸
사례 4: 서보 열 손상 &rarr\; 캘리브레이션 복구
- 레거시: 서보 교체&rarr\;기구부 재조립&rarr\;전체 재티칭&rarr\;검증 = \;수 일
- AMFX: 서보혼 재장착&rarr\;AI와 방향/오프셋 재계산&rarr\;자동 검증 = \;수 시간
- direction=-1, hp=-67.75 도출. FK/IK 전체 검증까지 AI와 함께
공통점: \;실패할수록 빨라진다 \;&mdash\; 실패가 즉시 다음 PDCA의 입력이 됨
12. 경험 DB &mdash\; 숙련공의 노하우를 데이터로
[사이클 1] PC 설치 → 실패 (BIOS 키 틀림)
→ 경험 DB: {board: "ASUS H81M-C", key: "F1"}
[사이클 2] 같은 보드 → DB 참조 → 즉시 성공
→ 경험 DB: {time: 25min, errors: 0}
[사이클 50] 새 보드 (Gigabyte) → 키 모름
→ AI 시행착오 → Del 키 발견
→ 경험 DB: {board: "Gigabyte B760", key: "Del"}
[사이클 100+] 대부분 플레이북만으로 완료
→ AI는 미지의 상황에서만 호출
→ 비용이 자연 수렴
레거시 vs AMFX 비교
| \; | 레거시 | AMFX |
|---|---|---|
| 노하우 저장 | 숙련공 머릿속 | 경험 DB |
| 전수 방법 | 도제식 (년) | DB 복사 (초) |
| 퇴직 시 | 노하우 소실 | DB 영구 보존 |
| 새 공정 | 0부터 시작 | 유사 경험 재활용 |
| 다른 현장 | 파견 (월) | 배포 (시간) |
솔직한 비판: 이상탐지 모델 자체는 쉽다
요즘 AI 이상탐지는 \;데이터만 있으면 딸깍이다:
- AutoEncoder 계열로 정상 패턴 학습 &rarr\; 이상 재구성 에러
- 시계열 모델 (LSTM, Transformer) &rarr\; 패턴 이탈 탐지
- 전통 ML (Isolation Forest, One-Class SVM) &rarr\; 충분히 잘 됨
- MLOps 파이프라인으로 데이터 갱신 &rarr\; 모델 드리프트 대응
모델 선택은 어렵지 않다. 진짜 어려운 건:
- 데이터를 어디서 구하나? \;&mdash\; 공장에 센서 달고 수 개월 수집? 고장 데이터는 사고가 나야 생긴다
- 어떤 데이터를 쌓아야 하나? \;&mdash\; 전류만? 진동만? &rarr\; 맥락 없으면 쓸 수 없다
- 실제 이상을 만나봤나? \;&mdash\; 논문의 벤치마크 데이터셋과 현장 데이터는 다르다
이 프로젝트의 접근: \;공정을 직접 만들어서 데이터를 발생시켰다.
- 버튼 프레스 반복 &rarr\; 정상 데이터 자동 누적
- 서보 나사 풀림, 기어 변형, 배선 용해 &rarr\; \;진짜 이상 데이터를 실제로 만났다
- 같은 row에 \;
{전류, 전압, 관절각도[6], TCP좌표, 동작, 결과}\;&rarr\; 맥락 있는 라벨링
데이터 파이프라인의 진짜 핵심: \;같은 row에 센서+동작+결과를 넣는 것. \;모델은 나중에 골라도 된다. \;라벨링된 실제 데이터를 가진 것이 경쟁력이다.
반면, 에이전트 기반 PC 설치는 수 개월 데이터를 모을 필요가 없었다. PDCA 환경(눈+손+판단+반복)이 연결되는 순간 \;에이전트가 바로 작업을 시작했고, 사람은 중간 검증만 했다.
이상탐지: \;데이터가 있어야 딸깍 &rarr\; 데이터를 만드는 게 진짜 일 에이전트 작업: \;환경이 있으면 딸깍 &rarr\; 환경을 만드는 게 진짜 일 이 프로젝트는 둘 다 했다.
13. 솔직한 한계 &mdash\; 이것도 인사이트
한계를 숨기지 않는 것이 경쟁력. \;이 한계가 다음 로드맵을 만든다.
$30 서보 로봇으로 못 하는 것
| 작업 | 결과 | 원인 | 대응 |
|---|---|---|---|
| USB 물리 삽입 | 불가능 | 백래시 ~2mm, 삽입력 부족 | 수동 1회 삽입 + TS3USB30 구상 |
| PC 본체 전원 버튼 | 압력 부족 | 서보 출력 <\; 버튼 압력 | 1mm 저압 택트 스위치로 교체 |
| 반복정밀도 | ~3mm | 기어 유격 | IK 0.2mm + Visual Servoing 보정 |
| 힘 제어 | 불가 | 위치 제어만 | "\;힘&rarr\;정확도"\; 전환, 저압 부품 사용 |
이것을 인정하고, 전자 스위칭을 구상(TS3USB30, $4)한 것이 "\;더 비싼 로봇을 사자"\;가 아니라 **"\;공정을 재정의하자"\;**로 이어졌다.
한계 &rarr\; 로드맵
| 현재 한계 | 개선 방향 |
|---|---|
| 기어 백래시 | 벨트/다이렉트 드라이브 |
| 구조 강성 부족 | 알루미늄 프레임+베어링 |
| 위치 제어만 | 토크/힘 제어 추가 |
| 힘 피드백 없음 | FSR/로드셀 at TCP |
SW 프레임워크(IK, Servoing, Agent)는 유효. \;HW가 바뀌어도 API 인터페이스로 분리 \;&rarr\; 로봇 교체 시 SW 재사용 100%
14. 자율주행처럼, 자율제조에도 레벨이 있다
| Level | 자율주행 | 자율제조 | AMFX 현재 |
|---|---|---|---|
| L0 | 수동 운전 | 수동 조립 | 사람이 USB 꽂고 키보드 침 |
| L1 | 크루즈 컨트롤 | 단일 자동화 | 로봇이 버튼만 누름 |
| L2 | 부분 자율 | 로봇+AI, 사람 감시(HIL) | O 달성 |
| L2&rarr\;L3 | \; | 일부 구간 완전 자율 달성 | &larr\; 현재 AMFX |
| L3 | 조건부 자율 | Plan-Execute, 예외 시만 사람 | &larr\; 다음 목표 |
| L4 | 고도 자율 | WoL+HID+캡처 무인 N대 | &larr\; 비전 |
| L5 | 완전 자율 | 새 HW/OS도 자가 대응 | &larr\; 미래 |
이미 L3에 진입하고 있는 근거:
| 구간 | 자율 수준 | 사람 개입 |
|---|---|---|
| BIOS 부팅 순서 변경 | Edge 100% 자율 \;(22 steps, Cloud 0회) | 없음 |
| 전원 버튼 프레스 | MCP 자율 \;(IK + 가드) | 없음 |
| Ubuntu 전체 설치 | Cloud LLM 자율 \;(BIOS&rarr\;설치&rarr\;로그인) | 없음 |
| USB 물리 삽입 | 수동 | 사람이 꽂음 \;(물리 한계) |
| SSD 고장 교체 | AI가 진단, 교체는 수동 | 예외 상황 |
사람이 개입하는 건 \;물리적 한계(USB 삽입)와 \;진짜 예외(하드웨어 고장)뿐이다. 이것이 L3의 정의 &mdash\; "\;Plan-Execute, 예외 시만 사람"\; &mdash\; 에 해당한다.
자율주행이 L2에서 L5로 가는 데 10년 걸렸다. 자율제조는 \;AI PDCA 가속 \;덕분에 훨씬 빠르게 진화할 수 있다 &mdash\; 실제로 이 프로젝트에서 수 주 만에 L2&rarr\;L3 진입을 경험했다.
15. $75 셀 &mdash\; 프로토 공정 프레임워크
┌──────────────────────────────────────┐
│ Proto Process Framework │
│ │
│ ┌────────┐ ┌────────┐ ┌────────┐ │
│ │ Cell 1 │ │ Cell 2 │ │ Cell 3 │ ...│
│ │ ESP32 │ │ ESP32 │ │ ESP32 │ │
│ │ Robot │ │ Robot │ │ Robot │ │
│ │ HID │ │ HID │ │ HID │ │
│ └───┬────┘ └───┬────┘ └───┬────┘ │
│ └──────────┼──────────┘ │
│ Edge AI Hub │
│ 오케스트레이터 │
│ + Claude API │
│ + 경험 DB │
└──────────────────────────────────────┘
셀 1대 원가: ESP32-CAM $5 + 로봇 $30 + Pico $4 + 전자 스위칭 $4 (구상) + HDMI 캡처 $10 = \;~$75/셀 (목표)
적용 가능한 시나리오
| 분야 | 작업 |
|---|---|
| IT 인프라 | PC N대 OS 설치 |
| 교육 | 실험 장비 셋업 반복 |
| 품질 검사 | 외관/기능 검사 |
| 연구실 | 시약 투입/측정 반복 |
| 수공업 | 조립/포장 반복 |
산업용 로봇은 비싸고, 대기업만의 것이었다. \;$75 셀 + AI = "\;누구나 생산기술 엔지니어"\;
16. 성능 비교 요약
Edge vs Cloud
| 지표 | Cloud LLM (Claude) | Edge 규칙 엔진 | 배율 |
|---|---|---|---|
| 추론 시간 | 7,435ms | 84ms | 88x |
| 정확도 | 100% (기준) | 100% | 동일 |
| 네트워크 | 필수 (인터넷) | 불필요 \;(오프라인) | - |
| 비용/호출 | ~$0.01 | $0 | &infin\; |
PDCA 가속
| 지표 | 레거시 생산기술 | AMFX (AI+전자제어) | 배율 |
|---|---|---|---|
| 1 PDCA 사이클 | 6~18주 | 수 분 | ~1000x |
| 측정 &rarr\; 분석 | 사람 집계 (시간~일) | HDMI+OCR+AI 즉시 (초) | ~100x |
| 변경 반영 | 물리 재가공 (일~주) | GPIO/코드 수정 (초~분) | ~1000x |
| 야간/주말 | 작업자 부재 &rarr\; 중단 | 무인 연속 가동 | &infin\; |
| 재현성 | 작업자별 편차 | 동일 코드 = 동일 결과 | 100% |
17. 우리가 배운 것
1. \;공정을 만들면 난제는 자연 발생한다 &mdash\; 선택이 아니라 발견
2. \;한계에 부딪히면 AI가 "\;다른 길"\;을 제안한다 &mdash\; 그게 더 싸고 빠르다
3. \;실패할수록 빨라진다 &mdash\; 실패가 즉시 다음 PDCA의 입력
4. \;기술을 쌓는 것보다 문제를 재정의하는 것이 답이었다
핵심 한 줄
"\;수작업을 공정으로, 공정을 자율 생산라인으로"\;
Team Davinci &mdash\; Industrial Edge AI Solution Challenge 2026 \;AMFX: Autonomous Manufacturing Framework with Edge AI
프로젝트 갤러리
프로젝트 제작 과정과 최종 결과물을 담은 이미지 갤러리입니다.
프로젝트 소개
아직 등록된 프로젝트 소개가 없습니다.
댓글 0개
아직 댓글이 없습니다. 첫 댓글을 남겨보세요!