K-디지털 트레이닝 프로젝트 학습계획서
| 과정명 | 융합_로보테크 AI 자율주행 로봇 개발자 과정_2회차 | |
| 훈련기간 | 2025-12-30 ~ 2026-07-16 | |
| 팀명 | MYMY | |
| 프로젝트명 | PACK(Picking arm And Carry Kit) | |
| 프로젝트 주제 | 군집 협업 기반 자율주행 피킹·운반 로봇 | |
| 프로젝트 기간 | 2025-05-18 ~ 2026-07-16 | |
| 팀 구성 및 역할 분담 | 성명 | 역할 |
| 윤우영 | PM / 리더 로봇 엔지니어 | |
| 길민준 | 팔로워 임베디드 엔지니어 | |
| 김아영 | 웹 백엔드 엔지니어 | |
| 강태민 | 통신·통합 엔지니어 | |
| 프로젝트 목표 및 배경 |
1. 프로젝트 선정 배경 - 중소 물류·제조 현장에서 자동화 수요가 증가하고 있으나, 고가의 산업용 로봇팔과 고정형 컨베이어 중심의 기존 자동화 방식은 초기 비용과 공간 제약으로 인해 낙후 환경에 도입하기 어려운 상황임. 이에 저가 운반 로봇 군집과 이동형 피킹 로봇을 결합해 비용 대비 효율을 극대화하는 유연한 자동화 시스템의 필요성이 대두되고 있음 2. 해결하고자 하는 문제 - 로봇팔 다수 배치의 높은 비용, 컨베이어의 고정 레이아웃 한계, 그리고 낙후 환경의 자동화 진입장벽을 해소하기 위해, 고가 장비인 로봇팔은 1대만 사용하고 저가 팔로워를 N대 확장하는 군집 협업 구조를 통해 피킹·분류·운반 전 과정을 자율적으로 수행하는 통합 시스템을 구현하고자 함 3. 최종 목표 및 기대 효과 - TurtleBot3 리더(SLAM·피킹·분류)와 Arduino 팔로워(ArUco 추종·운반)로 구성된 군집 협업 자율주행 시스템을 개발하고, MQTT 기반 서버 독립 통신과 웹 대시보드를 통해 실시간 모니터링·원격 제어를 제공함으로써 설비 투자 비용을 절감하고 레이아웃에 제약 없는 유연한 자동화를 실현함 |
|
| 프로젝트 추진 전략 |
1 핵심 부품 검증 및 개발 환경 구축 - TurtleBot3·3D 프린팅 기반 자체 제작 로봇팔(MG996R ×4)·Arduino 팔로워·ESP-01 등 핵심 부품의 호환성을 최우선 검증하고, ROS2 Humble·MQTT 브로커·Spring Boot 개발 환경을 구성하며, MQTT 토픽·ROS2 토픽·페이로드 형식을 포함한 인터페이스 정의서를 확정하여 모듈 간 독립 개발이 가능한 기반을 마련함 2. 시스템 아키텍처 설계 및 모듈별 병렬 개발 - MQTT 중심 5계층 구조와 서버 독립 동작 원칙에 따라 리더(SLAM·피킹)·팔로워(ArUco 추종·운반)·웹(대시보드·모니터링) 세 영역을 역할별로 분리 설계하고, FSM 상태 전이와 예외 시나리오(이탈·장애·서버 끊김)를 정의한 뒤 4인이 역할별로 병렬 구현을 진행함 3. 통합 테스트 및 시나리오 완성 - 리더-팔로워-서버 간 MQTT 통합 연동을 시작하고, 전체 10단계 시나리오(대기->검출->피킹->분류->투하->카운트->출발->이탈->대기->복귀)의 단계별 성공률을 검증하며, 리스크 대응(기본->고급 단계적 전환)을 반영하여 안정화·문서화·최종 발표를 완료함 |
|
| 예상 산출물 목록 | 1. 자율주행 로봇(리더) - SLAM Toolbox + Nav2로 자율주행하며, 자체 제작 로봇팔(MG996R ×4)로 물체를 피킹하고 HSV·YOLO 기반 색상 분류를 수행하는 TurtleBot3 리더 로봇 2. 군집 운반 로봇(팔로워 2대) - Arduino UNO + ESP-01 기반 저비용 운반 차량으로, ArUco 마커 추종으로 리더를 따르고 라인트레이싱으로 목적지에 정밀 도킹하여 물체를 운반하는 팔로워 로봇 3. 실시간 웹 대시보드 - Spring Boot + Thymeleaf 기반 웹 애플리케이션으로, 팔로워 적재 현황·로봇 위치·미션 진행률을 실시간 모니터링하고 원격 명령을 전송할 수 있는 관리 화면 4. MQTT 통신·관제 시스템 - Mosquitto 브로커 중심으로 모듈 간 직접 통신을 수행하고, MySQL에 미션 이력·센서 로그·팔로워 상태를 저장하며, 서버 끊김 시에도 로봇이 자율 수행을 유지하는 서버 독립 아키텍처 |
|
| 프로젝트 일정 및 협업 방식 | 1. 주차별 진행 계획 수립 - W1 2026-05-18 ~ 2026-05-22 핵심 부품 호환성 검증 인터페이스 정의서 확정 ROS2·MQTT·Spring Boot 개발 환경 구축 - W2 2026-05-25 ~ 2026-05-29 리더 SLAM·Nav2 단독 주행 로봇팔 픽업 테스트 팔로워 1대 차체 제작 MQTT 브리지 기본 구현 DB 설계 - W3 2026-06-01 ~ 2026-06-05 ArUco 정밀 정렬 YOLO 통합 팔로워 2대 마커 추종·라인트레이싱 FSM Task Manager 구현 - W4 2026-06-08 ~ 2026-06-12 리더-팔로워-서버 전체 통합 시나리오 1회 완주 목표 - W5 2026-06-15 ~ 2026-06-19 안정화 및 버그 수정 반복 시연 테스트 10회 중 7회 이상 성공 목표 - W6 2026-06-22 ~ 2026-06-26 차별화 기능 추가 최종 점검 10회 중 9회 이상 성공 목표 발표 영상 컷 확보 - W7 2026-06-29 ~ 2026-07-03 시연 영상 편집 발표 자료 초안 작성 코드 정리 - W8 2026-07-06 ~ 2026-07-10 산출물 최종 정리 - W9 2026-07-13 ~ 2026-07-16 최종 점검 발표 리허설 및 데모 환경 준비 2. 협업 도구 및 커뮤니케이션 방식 - GitHub로 코드 형상관리 및 이슈 기반 태스크 관리 Google Drive로 문서 공유 및 버전 관리 데일리 스탠드업과 위클리 리뷰 진행 3 테스트 및 검증 프로세스 정의 - 모듈 단위 테스트와 전체 시나리오 통합 테스트 병행 마일스톤별 성공 기준에 따른 단계적 검증 수행 리스크 발생 시 기본에서 고급으로 전환하는 단계적 대응 원칙 적용 및 리스크 한계 문서화 |
|
기획 보고서 수정 v2
심화 프로젝트 기획 보고서
이동 피킹 연동 자율주행 운반 로봇
TurtleBot3 + 로봇팔 + Arduino 팔로워 군집 협업 기반 운반 시스템
과정명: 로보테크 AI 자율주행 로봇 개발자 과정
팀 구성: 4인 1팀 (팀장 1 + 팀원 3)
수행 기간: 2026. 05. 20 (수) ~ 06. 30 (화) / 실작업 27일 + 마무리 2일
목차
1. 프로젝트 개요
1.1 추진 배경
1.2 핵심 아이디어
1.3 활용 분야 및 범용성
1.4 과업 목표
2. 핵심 동작 시나리오
2.1 시나리오 개요
2.2 상태 머신(FSM) 정의
2.3 분류 시나리오
3. 시스템 아키텍처
3.1 핵심 설계 원칙
3.2 시스템 구성도 (5계층)
3.3 데이터 흐름
3.4 ROS2 토픽 구조
3.5 MQTT 토픽 구조
4. 사용 기술 스택
4.1 로봇/자율주행 기술
4.2 IoT/임베디드 기술
4.3 웹/서버 기술
4.4 부트캠프 커리큘럼 매핑
5. 하드웨어 구성
5.1 리더 차량
5.2 팔로워 차량
5.3 부품 리스트
6. 4인 역할 분담
6.1 역할 배정
6.2 팀 리더의 사전 설계 책임
7. 일정 및 마일스톤
7.1 전체 일정 개요
7.2 간트차트
7.3 마일스톤 상세
8. 리스크 관리
8.1 핵심 부품 호환성 우선 검증
8.2 리스크별 대응
8.3 하드웨어 병목 분석 및 소프트웨어 해결 전략
9. 기대효과
9.1 산업적 효과
9.2 범용성
9.3 교육적 가치
10. 마무리
10.1 보충할 점 / 향후 발전 방향
1. 프로젝트 개요
1.1 추진 배경
산업 현장에서 물체를 집어 옮기는 작업은 로봇팔(매니퓰레이터)이 담당한다. 그러나 로봇팔은 한 대당 수천만 원에 달하는 고가 장비이며, 설치 위치가 고정되어 있어 작업 범위가 제한된다. 컨베이어 벨트를 설치하면 운반 문제는 해결되지만, 레이아웃이 고정되어 공정 변경 시 대규모 재시공이 필요하다.
특히 중소 물류센터, 낙후된 창고 등 예산과 공간이 부족한 현장에서는 자동화 도입 자체가 어렵다는 구조적 한계가 존재한다.
본 프로젝트는 이 한계를 정면으로 극복하기 위해, "비싼 장비는 1대만, 저렴한 운반 로봇은 여러 대" 라는 아키텍처를 제안한다. 로봇팔이 장착된 자율주행 리더 로봇 1대가 물체를 집고, Arduino 기반의 저비용 팔로워 로봇 N대가 군집을 이루어 운반을 분담하는 협업 시스템이다.
1.2 핵심 아이디어
본 프로젝트의 핵심 통찰은 단순하다. "비싼 것은 1대만, 싼 것은 여러 대." 로봇팔은 고가이므로 리더 로봇 1대에만 장착하고(본 프로젝트에서는 3D 프린터로 자체 제작한 4DOF 로봇팔을 사용), 운반만 담당하는 팔로워 로봇은 Arduino UNO + DC 모터로 구성하여 대당 수만 원 수준으로 제작한다.
이 아키텍처의 핵심 장점은 다음과 같다.
· 로봇팔 1대로 N배 효율: 팔로워가 운반을 분담하므로 리더는 피킹에만 집중한다.
· 레이아웃 자유: 컨베이어 없이 로봇이 직접 이동하므로 공정 변경이 즉각 가능하다.
· 확장 용이: 처리량을 늘리고 싶으면 팔로워만 추가하면 된다.
· 비용 효율: 고가 장비 최소화, 저비용 팔로워로 운반 커버리지를 확보한다.
1.3 활용 분야 및 범용성
본 프로젝트에서 제안하는 "리더 1대 + 팔로워 N대" 아키텍처는 특정 산업에 종속되지 않는 범용 패턴이다. 리더가 수행하는 작업(피킹, 분류)과 팔로워가 담당하는 운반을 분리한 구조 자체가 다양한 산업 현장에 그대로 적용 가능하다.
| 순위 | 활용 분야 | 적용 시나리오 | 리더 역할 | 팔로워 역할 |
| 1 | 물류센터 / 창고 (주력) |
피킹 + 분류 + 운반 일체화 | 로봇팔로 선반에서 물체 피킹 |
분류된 물체를 출하 구역으로 운반 |
| 2 | 트럭 군집주행 (확장 가능성) |
리더 트럭 1대 + 팔로워 트레일러 N대 |
선두 차량이 경로·속도 결정 |
후방 차량이 화물 운반 추종 |
| 3 | 공항 / 항만 | 수하물·컨테이너 운반 | 수하물 분류 로봇 | 분류된 수하물을 게이트별 운반 |
| 4 | 농업 | 수확물 운반 | 수확 로봇 | 수확물을 집하장으로 운반 |
| 5 | 병원 / 호텔 | 물품·식사 운반 | 물품 분류 스테이션 | 객실·병실별 배송 로봇 |
특히 트럭 군집주행(Truck Platooning)은 미국·유럽의 장거리 물류에서 이미 상용화가 진행 중인 분야로, 본 프로젝트의 리더-팔로워 아키텍처와 동일한 개념이 실제 도로 위에서 구현되고 있다.
1.4 과업 목표
본 섹션은 "프로젝트 목표"가 아닌 "과업 목표"로 정의한다. 부트캠프 과정에서 배운 기술 스택을 최대한 활용하고, 이전 PURE 프로젝트의 아쉬운 점을 보완하는 것이 과업의 핵심이다.
성과 목표:
· TurtleBot3 + 자체 제작 로봇팔(MG996R ×4, 3D 프린터 제작) 연동으로 이동 피킹(모바일 매니퓰레이션) 구현
· Arduino 팔로워 2대의 군집 협업 및 ArUco 마커 추종 기반 자율 운반 (도킹 시 라인트레이싱 병행)
· YOLO 객체 탐지를 활용한 물체 검출 및 색상 기반 분류
· MQTT 기반 이기종 시스템(ROS2 ↔ Arduino ↔ Spring Boot) 완전 통합
· 웹 대시보드를 통한 실시간 모니터링 및 원격 제어
· 전체 시나리오 10회 중 7회 이상 안정 성공 (최종 목표: 9회 이상)
이전 PURE 프로젝트 대비 보충 사항:
| PURE 아쉬운 점 | 이번 프로젝트 보충 |
| 단일 로봇 운용 | 다중 로봇 협업 시스템 (리더 1 + 팔로워 2) |
| YOLO 미사용 | YOLO 기반 물체 탐지 + Roboflow 커스텀 학습 |
| 로봇팔 미사용 | 자체 제작 로봇팔(MG996R ×4) + Arduino 연동 |
| WebSocket 미적용 | WebSocket 적용 시도 (여유 시) |
2. 핵심 동작 시나리오
2.1 시나리오 개요
아래는 전체 시스템이 한 사이클을 수행하는 과정을 일반인도 이해할 수 있는 언어로 설명한 것이다. 각 단계는 화살표로 연결되어 순서대로 진행된다.
① 대기 리더 로봇과 팔로워 2대가 픽업 스테이션(물건이 놓인 곳) 앞에 나란히 정렬하여 대기한다.
② 이동 및 물체 검출 리더 로봇이 SLAM 기반 자율주행으로 픽업 스테이션까지 이동한 뒤, 카메라가 픽업 스테이션 위의 물체를 YOLO(인공지능 객체 탐지 기술)로 인식한다.
③ 피킹 리더에 장착된 로봇팔(자체 제작 로봇팔(MG996R ×4))이 검출된 물체를 집어 올린다.
④ 분류 물체의 색상을 판별하여 어느 팔로워에 넣을지 결정한다. (예: 빨강 → 팔로워1, 파랑 → 팔로워2)
⑤ 이동 및 투하 리더가 해당 팔로워 위치까지 자율주행으로 미세 이동한 뒤, 로봇팔이 상자에 물체를 놓는다.
⑥ 카운트 증가 Task Manager(작업 관리자)가 해당 팔로워의 적재 개수를 +1하고, MQTT(IoT 통신 프로토콜)로 웹 대시보드에 전송한다.
⑦ 가득 참 판정 적재 개수가 N개에 도달하면, Task Manager가 해당 팔로워에 "출발" 명령을 보낸다.
⑧ 팔로워 이탈 (예외 시나리오) 가득 찬 팔로워는 ArUco 마커를 따라 리더로부터 이탈하고, 목적지 근처에서 라인트레이싱으로 정밀 도킹한 뒤 자율 이동한다. 이탈은 정상 흐름의 분기로, 리더는 이탈과 무관하게 다음 물체 검출을 계속 수행한다.
⑨ 잔여 팔로워 대기 아직 덜 찬 팔로워는 리더 옆에서 계속 대기하며 다음 투하를 기다린다.
⑩ 복귀 이동 팔로워가 목적지에서 물체를 내린 뒤, ArUco 마커 추종 경로를 역순으로 따라 픽업 스테이션으로 자율 복귀한다.
2.2 상태 머신(FSM) 정의
로봇의 전체 동작은 유한 상태 머신(FSM: Finite State Machine, 로봇이 현재 무엇을 하고 있는지를 상태로 정의하고, 조건에 따라 다음 상태로 전환하는 방식)으로 관리된다.
| 상태 | 설명 | 전환 조건 |
| IDLE (대기) |
리더와 팔로워가 픽업 스테이션에서 대기 | 물체 검출 시 → DETECT |
| DETECT (검출) |
YOLO/색상으로 물체 인식 및 위치 추정 | 물체 확인 시 → PICK |
| PICK (피킹) |
로봇팔이 물체를 집음 | 그립 성공 시 → CLASSIFY |
| CLASSIFY (분류) |
색상 판별 후 대상 팔로워 결정 | 팔로워 결정 시 → DROP |
| DROP (투하) |
해당 팔로워 상자에 물체 투하 | 투하 완료 시 → COUNT |
| COUNT (카운트) |
적재량 +1, 가득 참 여부 판정 | 가득 참 → DISPATCH 여유 있음 → IDLE |
| DISPATCH (출발) |
가득 찬 팔로워에 출발 명령 | 팔로워 이탈 후 → IDLE |
2.3 분류 시나리오
물체 분류는 색상 기반으로 수행한다. 카메라가 촬영한 이미지에서 HSV 색공간 변환 후 특정 색상 범위에 해당하는지 판별하며, YOLO와 병행하여 정확도를 높인다.
| 물체 색상 | 할당 팔로워 | 목적지 | 비고 |
| 빨강 계열 | 팔로워 1 | 목적지 A | HSV H: 0~10, 170~180 |
| 파랑 계열 | 팔로워 2 | 목적지 B | HSV H: 100~130 |
| 기타 | 팔로워 1 (기본값) | 목적지 A | 판별 불가 시 기본 할당 |
3. 시스템 아키텍처
3.1 핵심 설계 원칙
본 시스템의 설계는 두 가지 핵심 원칙을 따른다.
역할 분리 원칙(Separation of Concerns):
· 로봇 내부(주행, 맵핑, 피킹, 인식): ROS2가 전담한다.
· 팔로워 임베디드(추종, 라인트레이싱, 모터 제어): Arduino가 전담한다.
· 웹 모니터링/제어: Spring Boot가 전담한다.
· 세 영역은 MQTT 브로커를 통해 느슨하게 결합(Loose Coupling)되어, 각 영역의 독립적 개발·디버깅·확장이 가능하다.
느슨한 결합(Loose Coupling) — MQTT 중심 통신 + 서버 독립 동작:
MQTT(Message Queuing Telemetry Transport)는 IoT에서 널리 사용되는 경량 메시지 프로토콜이다. 발행-구독(Pub/Sub) 패턴으로 동작하며, 메시지를 보내는 쪽과 받는 쪽이 서로를 직접 알 필요가 없다. 본 시스템에서는 센서 데이터를 서버로 보내 처리하는 대신, 각 모듈이 MQTT 토픽을 통해 직접 데이터를 주고받는 구조를 취한다. 서버(Spring Boot)는 미션(행동 시퀀스)을 로봇 인터페이스에 전달하는 역할만 하며, 로봇은 미션을 수신한 뒤 서버 응답을 기다리지 않고 자율적으로 전체 수행을 완료한 후 결과만 서버로 전달한다. 이 설계 덕분에 서버가 일시적으로 끊겨도 로봇은 이미 수신한 미션을 독립적으로 수행할 수 있으며, 센서 추가나 변경 시에도 다른 영역에 영향을 최소화할 수 있다.
3.2 시스템 구성도 (5계층)
전체 시스템은 5개 계층이 MQTT 브로커를 중심으로 연결된다. 아래 표는 각 계층의 역할과 핵심 구성요소를 정리한 것이다.
| 계층 | 명칭 | 핵심 구성요소 | 역할 |
| 1 | 센서/임베디드 | Arduino UNO, ESP-01, IR 라인센서, 초음파, ESP32-CAM |
팔로워 차체 제어, 센서 데이터 수집, 무선 MQTT 통신 |
| 2 | 통신 미들웨어 | Mosquitto MQTT 브로커 | 모든 계층 간 메시지 중계 (Pub/Sub) |
| 3 | 로봇 제어 | TurtleBot3 + ROS2 (SLAM, Nav2, 로봇팔 Arduino 제어, FSM, YOLO) |
리더 자율주행, 로봇팔 피킹, 작업 관리 |
| 4 | 웹 백엔드 | Spring Boot + MySQL + REST API |
DB 저장, API 제공, MQTT 구독/발행 |
| 5 | 사용자 인터페이스 | 웹 대시보드 (Thymeleaf) + ngrok 외부 접속 |
실시간 모니터링, 원격 제어 |
3.3 데이터 흐름
시스템의 핵심 데이터 흐름을 두 경로로 나누어 설명한다.
경로 1: 센서 데이터 → 웹 대시보드 (모니터링)
경로 2: 리더 로봇 ↔ 팔로워 (작업 명령)
3.4 ROS2 토픽 구조 (예상)
| 토픽명 | 메시지 타입 | 발행 노드 | 구독 노드 | 설명 |
| /cmd_vel | Twist | Nav2 / Pure Pursuit | TurtleBot3 | 주행 속도 명령 |
| /scan | LaserScan | TurtleBot3 LiDAR | SLAM / Nav2 | 라이다 스캔 데이터 |
| /map | OccupancyGrid | SLAM Toolbox | Nav2 / 웹 | 생성된 지도 |
| /camera/image | Image | USB 카메라 | YOLO / ArUco | 카메라 영상 |
| /yolo/detect | Custom | YOLO 노드 | Task Manager | 객체 탐지 결과 |
| /arm/command | String (MQTT 명령) | Arduino 로봇팔 제어 | 자체 제작 로봇팔 | 로봇팔 MQTT 명령 (Arduino로 전달) |
| /task/state | String | Task Manager | 모니터링 | 현재 FSM 상태 |
3.5 MQTT 토픽 구조 (예상)
| 토픽 | 발행자 | 구독자 | 페이로드 예시 | 설명 |
| robot/state | ROS2 브리지 | Spring Boot | {"state":"PICK"} | 리더 FSM 상태 |
| robot/detect | ROS2 브리지 | Spring Boot | {"color":"red","x":320} | YOLO 검출 결과 |
| follower/1/count | Task Manager | Spring Boot | {"count":3,"max":5} | 팔로워1 적재량 |
| follower/1/cmd | Task Manager | ESP-01 (#1) | "GO" / "STOP" | 팔로워1 명령 |
| follower/2/count | Task Manager | Spring Boot | {"count":2,"max":5} | 팔로워2 적재량 |
| follower/2/cmd | Task Manager | ESP-01 (#2) | "GO" / "STOP" | 팔로워2 명령 |
| web/command | Spring Boot | ROS2 브리지 | "START" / "PAUSE" | 웹 원격 명령 |
4. 사용 기술 스택
4.1 로봇/자율주행 기술
| 기술 | 버전/상세 | 역할 |
| ROS2 | Humble Hawksbill | 로봇 미들웨어, 노드 통신(DDS), QoS |
| SLAM Toolbox | ROS2 패키지 | TurtleBot3 LiDAR 기반 실시간 지도 생성 |
| Nav2 | ROS2 Navigation Stack | 자율주행 경로 계획 + 장애물 회피 |
| Arduino 로봇팔 제어 | Arduino PWM 서보 제어2 | 자체 제작 로봇팔 관절 제어 (PWM) |
| Pure Pursuit | 직접 구현 (C++/Python) | 경로 추종 알고리즘 |
| A* 경로 탐색 | 직접 구현 | 최적 경로 탐색 + Safety Cost Map |
| YOLO | YOLOv8 / Roboflow | 탁구공·물체 객체 탐지 |
| ArUco 마커 | OpenCV aruco 모듈 | 팔로워 위치 식별, 정밀 정렬 |
| OpenCV | 4.x | 영상 처리, HSV 색상 분류 |
| Gazebo | Ignition / Classic | 시뮬레이션 환경 |
| RViz | ROS2 기본 | 실시간 시각화 (맵, 경로, 로봇 위치) |
4.2 IoT/임베디드 기술
| 기술 | 상세 | 역할 |
| Arduino UNO | ATmega328P | 팔로워 MCU, 모터·센서 제어 |
| ESP-01 (ESP8266) | Wi-Fi 모듈 | Arduino ↔ MQTT 브로커 무선 통신 |
| ESP32-CAM | Wi-Fi + 카메라 | 팔로워 마커 추적 (권장 부품) |
| MQTT | Mosquitto + paho-mqtt + Eclipse Paho (Arduino) |
발행-구독 메시지 브로커 |
| AFMotor 쉴드 v1 | Adafruit | DC 모터 4채널 드라이브 |
| HC-SR04 | 초음파 센서 | 전방 거리 측정, 충돌 방지 |
| TCRT5000 | IR 반사 센서 | 라인트레이싱 |
4.3 웹/서버 기술
| 기술 | 버전/상세 | 역할 |
| Spring Boot | 4.0.6 | 웹 백엔드 프레임워크 |
| MySQL | 8.x | 적재량, 작업 이력, 로봇 상태 영속화 |
| Thymeleaf | Spring 기본 템플릿 | 웹 대시보드 UI 렌더링 |
| REST API | Spring MVC | 프론트엔드 ↔ 백엔드 데이터 교환 |
| ngrok | 터널링 서비스 | 로컬 서버를 외부 HTTPS로 노출 |
| WebSocket (옵션) | Spring WebSocket | HTTP 폴링 → 실시간 양방향 통신 전환 |
4.4 부트캠프 커리큘럼 매핑 (STEP 1~6)
본 프로젝트는 부트캠프 전 과정(STEP 1~6)에서 배운 기술을 빠짐없이 활용한다. 아래 표는 각 STEP에서 배운 기술이 프로젝트의 어느 부분에 적용되는지 매핑한 것이다.
| STEP | 교육 영역 | 핵심 기술 | 프로젝트 적용 부분 |
| 1 | 로봇 임베디드 | C++/Python ROS2 노드, 멀티스레딩, 모듈화 |
Task Manager, 네비게이션 컨트롤러, MQTT 브리지 |
| 2 | 로봇 알고리즘 | C++ 알고리즘, Pure Pursuit 직접 구현 |
경로 추종 알고리즘, A* 경로 탐색 |
| 3 | ROS2 입문 | ROS2 Humble, DDS, QoS, Topic/Service/Action, RQt, CLI, 패키지 |
전체 ROS2 노드 구조, 런치 파일, 토픽 설계 |
| 4 | AI 센서퓨전 | OpenCV, YOLO, ArUco, 카메라 |
YOLO 물체 탐지, ArUco 정밀 정렬, HSV 색상 분류 |
| 5 | 자율주행 데이터랩 | 판다스/넘파이, SLAM, AMCL, A* 경로계획 |
SLAM 지도 생성, AMCL 위치 추정, 데이터 분석 |
| 6 | ROS2 응용 | 런치 파일, Nav2, 로봇팔 Arduino 제어, 센서융합, 비상정지, Gazebo, RViz |
Nav2 자율주행, Arduino 로봇팔 제어 로봇팔, Gazebo 시뮬, 비상정지 구현 |
추가로, 이전 프로젝트(PURE)에서 확보한 자산도 활용한다: Arduino UNO + ESP-01, MQTT(Mosquitto + paho-mqtt + Eclipse Paho), AFMotor, HC-SR04, Spring Boot + MySQL + Thymeleaf + ngrok, PyQt5(보조 디버깅).
5. 하드웨어 구성
5.1 리더 차량 (TurtleBot3 + 로봇팔)
TurtleBot3 Waffle Pi는 Raspberry Pi를 탑재한 교육·연구용 모바일 로봇 플랫폼이다. LiDAR, IMU, 카메라를 기본 탑재하며, ROS2와 완전 호환된다. 여기에 3D 프린터로 자체 제작한 4DOF 로봇팔(MG996R 서보모터 ×4)을 장착하여 이동 피킹이 가능한 리더 차량을 구성한다. 로봇팔은 Arduino에서 PWM 신호로 직접 제어하며, ROS2 노드와는 MQTT를 통해 피킹 명령을 주고받는다.
| 구성요소 | 사양 | 역할 |
| TurtleBot3 Waffle Pi | Raspberry Pi 4 탑재 | 리더 차량 본체, 자율주행 |
| 자체 제작 로봇팔(MG996R ×4) | 4DOF (3D 프린터 자체 제작, MG996R ×4) | 물체 피킹 및 투하 (3D 프린터 자체 제작) |
| LiDAR | 360° 2D 스캔 | SLAM 지도 생성, 장애물 감지 |
| USB 웹캠 | 720p+ | YOLO 객체 탐지, ArUco 인식 |
5.2 팔로워 차량 (Arduino 기반, 2대)
팔로워는 Arduino UNO를 MCU로 사용하는 저비용 운반 차량이다. DC 모터 2개로 구동되며, ESP-01을 통해 MQTT로 리더 및 서버와 통신한다. 추종 방식은 ArUco 마커 추종을 주력으로 하고, 좌표 기반 추종(MQTT로 리더 위치 수신)을 백업으로 사용한다. 목적지 도킹 시에만 IR 라인센서를 활용한 라인트레이싱으로 정밀 정렬한다. 각 팔로워에는 물체를 담는 상자가 장착되어 있으며, 팔로워 번호(1번, 2번)에 따라 유연하게 대열 위치를 변경할 수 있다. 특정 팔로워가 고장 시 나머지 팔로워가 해당 역할을 대신 수행하는 장애 대응 로직도 포함한다.
| 구성요소 | 수량 | 역할 |
| Arduino UNO | 2 | 팔로워 MCU |
| AFMotor 쉴드 v1 | 2 | DC 모터 4채널 드라이브 |
| DC 모터 + 바퀴 + 섀시 | 2세트 | 차체 구동 |
| ESP-01 (ESP8266) | 2 | Wi-Fi MQTT 통신 |
| IR 라인센서 (TCRT5000) | 4 (2대x2) | 라인트레이싱 |
| HC-SR04 초음파 | 2 | 전방 거리 측정 |
| 적재 상자 | 2 | 운반할 물체 보관 |
5.3 부품 리스트 (중요도별)
부품은 중요도에 따라 4단계(A~D)로 구분한다. 모든 부품을 한 번에 연결하기 어려울 수 있으므로, A(핵심) 부품부터 우선 확보하고 순차적으로 확장한다.
A. 핵심 부품 (이것이 없으면 프로젝트 불가)
| No | 품목 | 용도 | 수량 | 우선 검증 |
| 1 | TurtleBot3 Waffle Pi | 리더 차량 | 1 | W1 즉시 |
| 2 | 자체 제작 로봇팔(MG996R ×4) | 자체 제작 로봇팔 (MG996R ×4) | 1 | W1 최우선 검증 |
| 3 | Arduino UNO | 팔로워 MCU | 2 | W1 |
| 4 | DC 모터+바퀴+섀시 키트 | 팔로워 차체 | 2세트 | W1 |
| 5 | AFMotor 쉴드 v1 | DC 모터 드라이브 | 2 | W1 |
| 6 | ESP-01 (ESP8266) | 무선 MQTT 통신 | 2 | 보유 |
B. 권장 부품 (있으면 품질 향상)
| No | 품목 | 용도 | 수량 |
| 7 | ESP32-CAM | 팔로워 마커 추적 카메라 | 2 |
| 8 | USB 웹캠 (720p+) | 리더 YOLO/ArUco 인식 | 1 |
| 9 | ArUco 마커 인쇄물 | 위치 기준점 | 5~10장 |
| 10 | IR 라인센서 (TCRT5000) | 팔로워 라인트레이싱 | 4 (2대x2) |
| 11 | HC-SR04 초음파 | 전방 거리/충돌 감지 | 2 |
C. 옵션 부품 (시간 여유 시)
| No | 품목 | 용도 |
| 12 | RGB LED / 색상 마커 | 물체 색상 분류 보조 |
| 13 | 무게 센서 (로드셀) | 적재량 정밀 측정 (SW 카운트로 대체 가능) |
| 14 | 추가 팔로워 1대 | 3대 군집 시연 |
D. 인프라
| No | 품목 | 용도 |
| 15 | Ubuntu PC | Mosquitto + Spring Boot + MySQL 서버 |
| 16 | Wi-Fi 라우터 | 로컬 네트워크 |
| 17 | 검정 절연 테이프 | 라인트레이싱 트랙 제작 |
6. 4인 역할 분담
6.1 역할 배정
팀원 4인을 A/B/C/D 역할로 분담한다. 각 역할의 책임 영역은 아래와 같이 명확히 정의하되, 본인 배정은 팀 합의 후 확정 예정이므로 모두 (미정)으로 표시한다.
| 역할 | 담당 영역 | 주요 책임 | 주요 산출물 |
| A (미정) |
리더 차량 + 매니퓰레이션 |
TurtleBot3 SLAM/Nav2, 자체 제작 로봇팔 픽업, ArUco 정밀 정렬, YOLO 객체 검출 |
맵 파일, 픽업 노드, Arduino 로봇팔 제어 설정, YOLO 학습 모델 |
| B (미정) |
팔로워 임베디드 | Arduino 팔로워 차체 제작(2대), ArUco 마커 추종, 도킹 라인트레이싱, MQTT 통신, 모터 제어 |
팔로워 차량 2대, 아두이노 스케치, 회로도 |
| C (미정) |
통신/통합 | MQTT 브로커, ROS2 ↔ MQTT 브리지, FSM Task Manager, 적재 카운트, 시나리오 통합 |
브리지 노드, FSM 코드, launch 파일 |
| D (미정) |
웹 백엔드/ 대시보드 |
Spring Boot + MySQL, REST API, MQTT 구독, 실시간 맵·상태 시각화, ngrok 외부 접속 |
웹 서버 코드, 대시보드 페이지, DB 스키마 |
모든 팀원은 W4(4주차) 통합 테스트 단계부터 상호 영역을 이해하고 협업하며, 최종 발표 준비에 공동 참여한다.
6.2 팀 리더의 사전 설계 책임
팀 리더는 W1(1주차)에 전체 시스템의 인터페이스를 사전에 견고하게 설계할 책임이 있다. 프로젝트 진행 중 새로운 센서가 추가되거나 기존 센서가 변경될 경우, 다른 모듈에 미치는 영향을 최소화할 수 있도록 아래 절차를 수행한다.
· 인터페이스 정의서 작성: MQTT 토픽명, 페이로드 형식, ROS2 토픽 구조를 W1에 확정한다.
· 센서 추가/변경 영향 분석 절차:
· 1) 변경 요청서 작성 (어떤 센서를, 왜, 어디에)
· 2) 영향 범위 식별 (MQTT 토픽, ROS2 노드, DB 스키마, 웹 API 중 어디가 변경되는지)
· 3) 팀원 합의 후 반영
· 모듈 경계 명확화: 각 역할(A/B/C/D)의 입출력 인터페이스를 정의하여, 한 영역의 변경이 다른 영역에 전파되지 않도록 방화벽을 구축한다.
7. 일정 및 마일스톤
7.1 전체 일정 개요
총 수행 기간: 2026. 05. 20 (수) ~ 06. 30 (화), 가용 평일 29일 (공휴일 6/3 제외). 개발 27일 + 마무리 2일(영상 1일 + PPT/리허설 1일)로 구성된다. 각 역할(A/B/C/D)은 병렬로 진행하되, W4부터 전원 통합 테스트에 돌입한다.
7.2 간트차트 (병렬 진행 + 마일스톤)
| 주차 | 기간 | 평일 | 역할 A (리더+팔) |
역할 B (팔로워) |
역할 C (통신/통합) |
역할 D (웹) |
마일스톤 |
| W1 | 5/20~ 5/22 |
3일 | 설계 확정 ROS2 WS 세팅 |
부품 확인 팔로워 설계 |
MQTT 브로커 구축 |
Spring Boot 프로젝트 생성 |
핵심 부품 호환 검증 완료 설계서 확정 |
| W2 | 5/25~ 5/29 |
5일 | SLAM + Nav2 로봇팔 픽업 단독 동작 |
팔로워 1대 차체 제작 모터 동작 |
MQTT 브리지 기본 구현 |
DB 설계 기본 페이지 |
M1: 리더 단독 픽업 성공 팔로워 1대 주행 센서값→웹 |
| W3 | 6/1~6/5 (6/3 제외) |
4일 | ArUco 정렬 YOLO 통합 |
팔로워 2대 마커/라인 추종 |
FSM Task Manager |
실시간 맵 REST API |
M2: 팔로워 추종 성공 FSM 1회 동작 |
| W4 | 6/8~ 6/12 |
5일 | 전체 통합 | 전체 통합 | 전체 통합 | 전체 통합 | M3: 전체 시나리오 1회 성공 |
| W5 | 6/15~ 6/19 |
5일 | 안정화 버그 수정 |
안정화 버그 수정 |
반복 시연 테스트 |
ngrok WebSocket(옵션) |
M4: 10회 중 7회 이상 성공 |
| W6 | 6/22~ 6/26 |
5일 | 차별화 기능 | 차별화 기능 | 최종 점검 | 최종 점검 | M5: 10회 중 9회 이상 성공 영상 컷 확보 |
| W7 | 6/29~ 6/30 |
2일 | 영상 편집 | 영상 보조 | PPT 마무리 | 리허설 | M6: 최종 산출물 완성 |
* W1~W3은 역할별 병렬 진행, W4~W6은 전원 통합. 예비일은 W4~W6에 분산 배치.
7.3 마일스톤 상세
| 마일스톤 | 시점 | 성공 기준 |
| M1: 개별 모듈 동작 | W2 종료 (5/29) |
리더 단독 픽업 성공, 팔로워 1대 주행 성공, 센서값이 웹에 표시 |
| M2: 서브시스템 연동 | W3 종료 (6/5) |
팔로워가 리더를 추종 성공, FSM 1회 동작 확인 |
| M3: 전체 시나리오 1회 | W4 종료 (6/12) |
대기→검출→피킹→분류→투하→이탈→복귀 전체 1회 성공 |
| M4: 안정성 확보 | W5 종료 (6/19) |
동일 시나리오 10회 중 7회 이상 성공 |
| M5: 최종 완성 | W6 종료 (6/26) |
10회 중 9회 이상 성공, 발표 영상 컷 확보 |
| M6: 산출물 | W7 종료 (6/30) |
영상 편집 완료, PPT 마무리, 리허설 완료 |
8. 리스크 관리
8.1 핵심 부품 호환성 우선 검증 (W1)
W1(1주차, 5/20~5/22)에 다음 핵심 부품의 호환성을 최우선으로 검증한다. 검증 실패 시 즉시 대안으로 전환하여 일정 지연을 방지한다.
| 검증 대상 | 검증 내용 | 실패 시 대안 |
| 자체 제작 로봇팔(MG996R ×4) + TurtleBot3 |
Arduino 로봇팔 제어 연동, 그리퍼 동작, 탁구공 피킹 가능 여부 |
그리퍼 단순화 또는 더 큰 물체(스티로폼 큐브)로 변경 |
| ESP32-CAM (팔로워 카메라) |
영상 처리 성능, ArUco 인식 속도 |
IR 마커 추종으로 전환 (광센서 좌우 비교 방식) |
| ESP-01 + MQTT 통신 |
Wi-Fi 연결 안정성, MQTT 메시지 지연 |
보유 재고로 즉시 테스트 가능 |
원칙: 고성능 방식이 불가능할 경우, 미리 정의해둔 저성능 또는 제거 옵션으로 즉시 전환한다. 이전 프로젝트(PURE)에서 미세먼지 모듈의 호환성 문제로 시간을 소모한 경험을 반영하여, 이번에는 W1에 핵심 부품 검증을 최우선으로 배치하였다.
8.2 리스크별 대응 (저성능/제거 옵션)
| 리스크 | 영향도 | 대응 (저성능 옵션) | 대응 (제거 옵션) |
| 로봇팔 픽업 정밀도 부족 |
높음 | 그리퍼 단순화, 더 큰 물체로 변경 |
수동 투입 후 운반만 자동화 |
| 팔로워 카메라 처리 한계 |
중간 | IR 마커 추종 (광센서 좌우 비교) |
카메라 제거, 순수 IR만 사용 |
| 라인트레이싱 정확도 부족 |
중간 | 트랙 폭 확대, 속도 저감 |
시간 기반 이동 (고정 시간 직진) |
| YOLO 학습 데이터 부족 |
중간 | 색상 기반 검출 (HSV 필터링) |
HSV만으로 전체 분류 |
| 다중 팔로워 충돌 |
높음 | 팔로워 1대로 축소 시연 |
시뮬레이션으로 다중 시연 대체 |
| Spring Boot 외부 접속 실패 |
낮음 | ngrok 대신 로컬망 시연 |
- |
| WebSocket 미적용 |
낮음 | HTTP 폴링 유지 (PURE와 동일) |
폴링으로 충분 |
8.3 하드웨어 병목 분석 및 소프트웨어 해결 전략
본 프로젝트는 교육용 하드웨어(TurtleBot3 Waffle Pi, Arduino UNO)를 사용하므로, 산업용 장비 대비 연산·전원·통신에서 병목이 발생할 수 있다. 추가 부품 구매 없이 소프트웨어적으로 해결하는 전략을 사전에 수립한다.
8.3.1 Raspberry Pi 4B 연산 한계 — 노드 분산 전략
TurtleBot3 Waffle Pi에 탑재된 Raspberry Pi 4B(4GB RAM)는 SLAM + Nav2만으로도 CPU 점유율이 60~80%에 달한다. 여기에 YOLO(객체 탐지)를 동시에 실행하면 메모리 부족과 프레임 드롭이 발생한다. 로봇팔은 Arduino에서 독립 제어하므로 Pi의 연산 부하에 영향을 주지 않는다.
| 작업 | Pi 4B 부하 | 단독 실행 가능 여부 |
| SLAM Toolbox | CPU 20~30% | 가능 |
| Nav2 (costmap + planner) | CPU 30~50% | 가능 (SLAM과 동시 시 한계) |
| 로봇팔 관절 제어 | Pi 부하 없음 (Arduino) | Pi와 무관, 항상 가능 |
| YOLO v8n 추론 | CPU 100%, 2~3 FPS | Pi에서 실시간 불가 |
| 카메라 + OpenCV | CPU 15~25% | 해상도 320x240이면 감당 |
소프트웨어 해결 전략 — ROS2 리모트 노드 분산:
ROS2 DDS(Data Distribution Service)는 네트워크상의 여러 머신에서 노드를 분산 실행할 수 있다. 같은 Wi-Fi 네트워크에서 ROS_DOMAIN_ID만 일치하면 자동으로 노드가 발견(Discovery)되므로, 추가 설정 없이 연산을 분리할 수 있다. 이전 PURE 프로젝트에서도 이 방식을 사용하였다.
| 실행 위치 | 담당 노드 | 이유 |
| Raspberry Pi 4B (TurtleBot3 내장) |
turtlebot3_bringup (모터, LiDAR, IMU) |
하드웨어 직접 제어는 로봇 내부에서만 가능 |
| Ubuntu PC (원격) |
SLAM Toolbox Nav2 (planner + costmap) 로봇팔 관절 제어 YOLO 추론 노드 Task Manager (FSM) MQTT 브리지 ArUco 인식 |
CPU/RAM 집약적 연산은 PC에서 처리. SSH로 Pi bringup 후 PC에서 나머지 전부 실행 |
구현 방법: launch 파일에서 SSH를 통해 Pi의 bringup 노드를 원격 실행하고, PC 측에서 나머지 모든 노드를 실행한다. PURE 프로젝트의 air_clean_all.launch.py가 이 구조를 이미 구현해두었으므로, 동일한 패턴을 재사용한다.
8.3.2 전원 관리 — 동시 부하 회피 소프트웨어 시퀀싱
TurtleBot3 내장 배터리(11.1V LiPo, 1800mAh)는 주행 시 약 2A를 소비한다. 자체 제작 로봇팔의 MG996R 서보 4개가 동시 구동되면 피크 약 2.5A까지 소비하므로, 주행과 피킹을 동시에 수행하면 전압 강하 위험이 있다. 다만 MG996R는 Dynamixel 대비 전류 소비가 낮아 별도 전원(5V BEC)으로 분리 공급하면 안정적이다. 팔로워의 ESP-01도 Wi-Fi 전송 시 순간 300mA 피크가 발생하여 Arduino의 3.3V 레귤레이터에 부담을 준다.
소프트웨어 해결 전략 — 동작 시퀀싱(동시 부하 금지):
FSM(상태 머신)에서 주행과 로봇팔 동작이 동시에 실행되지 않도록 상태를 분리한다. 즉, "이동 중에는 팔을 접고 고정" / "피킹 중에는 바퀴를 정지"하는 배타적 실행 원칙을 적용한다.
| FSM 상태 | 주행 모터 | 로봇팔 서보 | 전류 합계 (예상) | 안전 여부 |
| IDLE (대기) | 정지 | 접힘 (PWM OFF) | ~0.3A | 안전 |
| 이동 중 (Nav2) | 구동 (~2A) | 접힘 (PWM OFF) | ~2.3A | 안전 |
| DETECT (검출) | 정지 | 접힘 (PWM OFF) | ~0.5A | 안전 |
| PICK (피킹) | 정지 | 구동 (~2.5A 피크) | ~2.8A | 주행 정지로 안전 |
| DROP (투하) | 미세이동 (~0.5A) | 구동 (~1.5A) | ~2.0A | 저속이라 안전 |
추가 소프트웨어 보호 조치:
· 배터리 전압 모니터링: TurtleBot3의 /battery_state 토픽을 Task Manager가 구독하여, 전압이 10.5V 이하로 떨어지면 피킹 동작을 중단하고 대기 상태로 전환한다.
· MG996R PWM OFF: 팔을 사용하지 않는 상태(이동, 대기)에서는 서보 PWM 신호를 끊어서 전류 소비를 최소화한다.
· 팔로워 ESP-01 전송 간격 조절: MQTT 발행 주기를 2~3초로 제한하여 Wi-Fi 전송 피크를 분산한다. 명령 수신(Subscribe)은 항상 대기하되, 발행(Publish)은 타이머로 제어한다.
8.3.3 통신 안정성 — ESP-01 MQTT 재연결 및 QoS 전략
ESP-01(ESP8266)은 저가 Wi-Fi 모듈로, TCP 연결이 불안정하여 MQTT 브로커와의 연결이 수시로 끊길 수 있다. 특히 팔로워 2대 + TurtleBot3 + Ubuntu PC + 스마트폰이 같은 공유기에 접속하면 채널 경합으로 패킷 손실이 증가한다.
소프트웨어 해결 전략:
(1) Arduino 스케치 — 자동 재연결 로직:
ESP-01의 MQTT 클라이언트(Eclipse Paho)에 연결 끊김 감지 + 자동 재연결 루프를 구현한다. 연결이 끊어지면 3초 간격으로 최대 10회 재연결을 시도하고, 재연결 중에는 모터를 정지하여 안전을 확보한다. PURE 프로젝트에서 이미 이 패턴을 사용했으므로 코드를 재활용할 수 있다.
(2) MQTT QoS 레벨 전략:
| 메시지 유형 | QoS | 이유 |
| 팔로워 센서 데이터 (주기적 발행) |
QoS 0 (최대 1회) |
손실되어도 다음 주기에 재전송. 대역폭 절약 우선. |
| 팔로워 명령 (GO/STOP) |
QoS 1 (최소 1회) |
명령 손실 시 팔로워가 멈추지 않으므로 반드시 전달 보장. |
| 웹 원격 명령 | QoS 1 (최소 1회) |
사용자 의도가 반영되어야 하므로 전달 보장. |
(3) Last Will and Testament (LWT) 설정:
ESP-01이 비정상 연결 해제될 경우, MQTT 브로커가 자동으로 "팔로워 오프라인" 메시지를 발행하도록 LWT(유언 메시지)를 설정한다. Task Manager는 이 메시지를 수신하면 해당 팔로워에 대한 투하 명령을 보류하고, 웹 대시보드에 경고를 표시한다.
(4) 네트워크 부하 분산:
· MQTT 메시지 페이로드를 최소화한다. JSON 대신 짧은 문자열("GO", "STOP", "3/5") 사용을 기본으로 하고, 상세 데이터는 웹 API 폴링으로 분리한다.
· 카메라 영상은 Wi-Fi로 스트리밍하지 않는다. USB로 PC에 직결하거나, Pi에서 처리 후 결과(좌표, 클래스명)만 토픽으로 발행한다.
· 팔로워 2대의 MQTT 발행 타이밍을 엇갈리게 설정(팔로워1: 0초, 2초, 4초... / 팔로워2: 1초, 3초, 5초...)하여 동시 전송 충돌을 방지한다.
9. 기대효과
9.1 산업적 효과
본 프로젝트가 실제 산업 현장에 도입될 경우, 다음과 같은 효과를 기대할 수 있다.
· 로봇팔 비용 절감: 고가 로봇팔 1대 + 저가 팔로워 N대 구성으로 초기 투자 비용을 대폭 절감한다.
· 레이아웃 유연성: 컨베이어 없이 로봇이 직접 이동하므로 공정 변경 시 즉각 대응 가능하다.
· 확장 용이성: 처리량 증가 시 팔로워만 추가하면 되므로, 점진적 확장이 가능하다.
· 낙후 환경 도입 가능: 고가 설비를 도입할 여력이 없는 중소 물류센터, 낙후된 창고, 소규모 제조 현장에서도 저비용으로 자동화를 도입할 수 있다. 이는 산업 자동화의 진입 장벽을 낮추는 효과가 있다.
9.2 범용성
"리더 1대 + 팔로워 N대" 아키텍처는 특정 산업에 종속되지 않는 범용 패턴이다. 물류센터의 피킹·운반부터, 트럭 군집주행(미국·유럽 장거리 물류), 공항 수하물 운반, 농업 수확물 운반, 병원·호텔 물품 배송까지 동일한 아키텍처로 적용할 수 있다. 리더의 작업(피킹 → 수확 → 분류 등)만 교체하면 팔로워의 운반 역할은 그대로 유지된다.
9.3 교육적 가치
본 프로젝트는 부트캠프 전 과정(STEP 1~6)에서 배운 기술을 하나의 시스템으로 통합하는 최종 프로젝트이다.
· ROS2 + 자율주행 + 로봇팔 + 컴퓨터 비전 + IoT + 웹 — 6개 기술 영역의 완전 통합
· MQTT 기반 이기종 시스템 통합 설계 경험
· 다중 로봇 협업 시스템 구현 경험
· YOLO 커스텀 학습 및 실시간 추론 경험
· 하드웨어(Arduino 차체 제작) + 소프트웨어(ROS2/Spring Boot) 풀스택 경험
10. 마무리
10.1 보충할 점 / 향후 발전 방향
본 기획 단계에서 확정하지 못한 사항과, 프로젝트 완료 후 발전시킬 수 있는 방향을 정리한다.
기획 단계 보충 필요 사항:
· 본인 역할 확정: 팀 합의 후 A/B/C/D 중 배정 확정
· YOLO 학습 데이터: 탁구공 데이터셋 수집 및 Roboflow 학습 계획 구체화
· 팔로워 상자 규격: 적재 가능 물체 크기 및 개수 확정
· 팔로워 카메라 방식: W1 검증 후 ArUco 마커 추종용 카메라(ESP32-CAM 또는 USB 캠) 최종 결정
향후 발전 방향:
· 팔로워 대수 확장: 3대 이상 군집으로 확장하여 대규모 운반 시연
· 딥러닝 기반 물체 분류: 색상뿐 아니라 형태·재질 기반 분류로 고도화
· WebSocket 실시간 통신: HTTP 폴링을 WebSocket으로 전환하여 반응속도 개선
· 자동 충전 도킹: 팔로워의 배터리 잔량 감지 + 충전 스테이션 자동 도킹
· ROS2 다중 로봇 네임스페이스: 팔로워도 ROS2 노드로 전환하여 완전한 ROS2 기반 군집 시스템 구현
· 실제 산업 현장 적용: 교육용을 넘어 실제 중소 물류센터 파일럿 운영
— 끝 —
'로보테크AI' 카테고리의 다른 글
| 융합_로보테크 AI 자율주행 로봇 개발자 과정-26/05/22 (0) | 2026.05.22 |
|---|---|
| 융합_로보테크 AI 자율주행 로봇 개발자 과정-26/05/21 (0) | 2026.05.21 |
| 융합_로보테크 AI 자율주행 로봇 개발자 과정-26/05/19[멘토링] (0) | 2026.05.19 |
| 융합_로보테크 AI 자율주행 로봇 개발자 과정-26/05/18 (0) | 2026.05.18 |
| 융합_로보테크 AI 자율주행 로봇 개발자 과정-26/05/14[프롬프트 + 웹] (0) | 2026.05.14 |