콘테스트 프로젝트 진행 상황
각 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개
아직 댓글이 없습니다. 첫 댓글을 남겨보세요!