이번 프로젝트는 지금까지 학습한 ROS 2 Humble, WEGO LIMO, SLAM, Navigation2, 카메라 영상처리, YOLO 객체 인식, 딥러닝, TensorRT, ROS 2 노드 개발 및 시스템 자동화 기술을 하나의 실제 이동 로봇 서비스로 통합하는 팀 프로젝트입니다.

단순히 예제 프로그램을 실행하거나 로봇을 움직이는 수준이 아니라, 실제 서비스 로봇 개발 과정과 유사하게

서비스 아이디어 선정 → 사용자 요구사항 정의 → 시스템 설계 → ROS 2 프로그램 개발 → 지도 작성 → Nav2 자율주행 → YOLO 인식 → 시스템 통합 → 시험 → 문서화 → 발표

과정을 수행합니다.

프로젝트에서 가장 중요한 것은 기능의 개수가 아닙니다.

실제 WEGO LIMO에서 처음부터 끝까지 반복적으로 동작하는 완성도 높은 시스템을 만드는 것이 가장 중요합니다.

1. 프로젝트 개요

1) 프로젝트 주제

WEGO LIMO를 이용한 ROS 2 이동 로봇 서비스 개발

2) 프로젝트 기간

2026년 9월 3일 목요일 ~ 2026년 9월 18일 금요일

주말을 제외하면 실제 프로젝트 수행일은 총 12일입니다.

3) 프로젝트 결과 발표

2026년 9월 18일 금요일

4) 개발 환경

플랫폼: WEGO / AgileX LIMO PRO
컴퓨팅 보드: NVIDIA Jetson Orin Nano 계열
운영체제: Ubuntu 22.04 Desktop
ROS: ROS 2 Humble
자율주행: Navigation2
SLAM: Cartographer 또는 팀에서 선정한 ROS 2 SLAM
영상처리: OpenCV
객체 인식: YOLO11n
딥러닝: TensorFlow / YOLO
GPU 최적화: TensorRT
센서:
- 2D LiDAR
- Depth Camera
- IMU
- Wheel Encoder
구동 방식: 4륜 모바일 로봇
협업: Git / GitHub

2. WEGO LIMO 기본 ROS 2 환경

교육에서 사용하는 주요 패키지는 다음과 같습니다.

limo_base
 └─ LIMO 하부 모터 및 차량 제어

limo_bringup
 └─ LIMO 하드웨어, 센서 및 로봇 시스템 통합 실행

limo_description
 └─ URDF, Robot Model, TF

limo_msgs
 └─ LIMO 전용 ROS 2 메시지

limo_car
 └─ Gazebo 시뮬레이션

프로젝트에서는 Turtlebot3 로봇 프로젝트와 유사하게 기존 LIMO 패키지를 그대로 수정하기보다는 가능한 한 팀 전용 패키지를 별도로 만들고 기존 LIMO 패키지를 의존성으로 사용하는 구조를 권장합니다.

예를 들어 Unity 팀이라면 다음과 같이 구성할 수 있습니다.

unity_ws/
└── src/
    ├── unity_bringup/
    ├── unity_navigation/
    ├── unity_mission/
    ├── unity_vision/
    ├── unity_interfaces/
    ├── unity_audio/
    └── unity_utils/

각 패키지의 역할은 다음과 같이 구분할 수 있습니다.

unity_bringup
 └─ 전체 시스템 통합 실행

unity_navigation
 └─ SLAM, Localization, Nav2, Map, Waypoint

unity_mission
 └─ 서비스 시나리오, Mission Manager, State Machine

unity_vision
 └─ Camera, OpenCV, YOLO11, 객체 인식

unity_interfaces
 └─ 사용자 정의 msg, srv, action

unity_audio
 └─ 효과음 및 음성 안내

unity_utils
 └─ 로그, 상태 확인, 공통 함수

팀 이름에 따라 unity_, dync_, ninjatt_, ros2run_ 등의 접두어를 사용하는 것을 권장합니다.

3. 프로젝트 작업 공간

각 팀은 지정된 GitHub 저장소를 사용합니다.

GitHub에는 프로그램 소스만 올리는 것이 아닙니다.

다음 자료도 프로젝트 결과물로 함께 관리합니다.

소스 프로그램
설계 문서
지도
Nav2 파라미터
Waypoint
Trajectory
YOLO 설정
YOLO 모델 정보
Launch 파일
시험 결과
실행 방법
사진
그래프
README

4. 프로젝트 수행 공간

이번 프로젝트에서는 강의실 내부의 테스트베드만 사용하는 것이 아닙니다.

다음 공간을 프로젝트의 실제 서비스 환경으로 사용합니다.

강의실 내부
강의실 내부 로봇 테스트베드
20층 복도
휴게 공간
학원 사무실 공용 구간
강사가 허용한 기타 공용 주행구간

각 팀은 이 공간을 직접 조사하여 서비스 시나리오를 설계해야 합니다.

5. Wi-Fi가 끊기는 환경을 반드시 고려합니다

이번 프로젝트에서 매우 중요한 조건입니다.

강의장에서 복도로 조금 이동하면 Wi-Fi가 끊어지는 구간이 있습니다.

그러나 LIMO 내부의 Jetson에서 Nav2와 Mission 프로그램이 실행되고 있다면 Wi-Fi가 끊기더라도 로봇 자체적으로 경유점 주행을 수행할 수 있습니다.

따라서 이번 프로젝트에서는 Wi-Fi 연결을 전제로 시스템을 설계해서는 안 됩니다.

권장 시스템 구조는 다음과 같습니다.

[외부 개발 PC]
        │
        │ Wi-Fi
        │
        ▼
[WEGO LIMO / Jetson Orin Nano]
        │
        ├─ limo_bringup
        ├─ Localization
        ├─ Nav2
        ├─ Mission Manager
        ├─ Waypoint Manager
        ├─ YOLO
        ├─ Camera Processing
        ├─ Audio
        └─ Logging

핵심 서비스 프로그램은 모두 LIMO 내부 Jetson에서 실행해야 합니다.

외부 PC는 가능한 한 다음 용도로 제한합니다.

개발
SSH
RViz2
상태 모니터링
로그 분석
디버깅

지도, Waypoint, YOLO 모델, 설정 파일, 음성 파일 등 실제 임무에 필요한 자료는 LIMO 내부에 존재해야 합니다.

6. 통신 단절 시 동작도 설계해야 합니다

예를 들어 다음과 같이 설계할 수 있습니다.

1) 자율주행 중 Wi-Fi 단절

Mission 수행 중
        ↓
Wi-Fi 단절
        ↓
Nav2 및 Mission은 계속 수행
        ↓
기존 Waypoint 주행 계속

2) 원격 수동조작 중 Wi-Fi 단절

Teleoperation 수행
        ↓
Wi-Fi 단절
        ↓
속도 명령 Timeout
        ↓
로봇 정지

Wi-Fi가 끊겼을 때 로봇이 어떻게 행동할지는 반드시 사용자 요구사항과 시스템 요구사항에 명시해야 합니다.

7. 프로젝트 최종 목표

각 팀은 다음 기능을 기본 목표로 합니다.

실제 서비스를 가정한 이동 로봇 서비스 시나리오를 선정합니다.
팀원 4~5명의 역할을 명확하게 분담합니다.
팀별 ROS 2 작업공간과 패키지를 구성합니다.
강의실과 20층 주행 공간을 직접 SLAM합니다.
다른 팀의 지도를 사용하지 않습니다.
GIMP 등을 이용해 지도를 편집합니다.
주행금지 구역을 직접 설정합니다.
작성한 지도에서 Localization을 수행합니다.
Nav2를 이용해 자율주행합니다.
최소 20개 이상의 경유점을 정의합니다.
최소 4개 이상의 Trajectory를 정의합니다.
이동 장애물을 자연스럽게 회피합니다.
두 대의 로봇이 서로 교차하는 상황에서도 충돌하지 않고 주행합니다.
목표점 도착 정밀도 5cm 이내를 목표로 Nav2를 조정합니다.
팀별 특정 객체를 YOLO로 학습합니다.
YOLO 객체 인식 결과를 실제 서비스 동작에 사용합니다.
딥러닝을 이용한 트랙 주행은 서비스에 사용하지 않아도 되지만 실행 결과를 동영상으로 제출하시기 바랍니다.
효과음 또는 음성 안내 기능을 적용합니다.
전원 인가 후 필요한 프로그램이 자동 실행되도록 구성합니다.
로봇의 시작 위치도 초기화 과정에서 설정합니다.
Wi-Fi가 끊겨도 자율 임무를 수행할 수 있도록 합니다.
전체 서비스 시나리오를 반복 시험합니다.
요구사항과 설계 문서를 작성합니다.
모든 결과를 GitHub에 정리합니다.

8. 서비스 시나리오를 먼저 결정합니다

프로젝트 첫날부터 코딩을 시작하지 않습니다.

먼저 누가, 어디에서, 무엇을 위해 이 로봇을 사용하는가를 결정해야 합니다.

좋지 않은 주제의 예는 다음과 같습니다.

SLAM을 한다.
Nav2를 사용한다.
YOLO를 사용한다.
카메라를 사용한다.

이것은 서비스 시나리오가 아니라 기술 목록입니다.

서비스 시나리오는 다음과 같이 작성해야 합니다.

로봇이 학원 사무실 앞에서 대기한다.

사용자가 안내 임무를 시작한다.

로봇이 방문자의 목적지를 확인한다.

지정된 강의실까지 자율주행한다.

복도에서 사람을 만나면 속도를 줄이거나 회피한다.

특정 객체 또는 표지판을 YOLO로 인식한다.

목적지에 도착하면 음성으로 안내한다.

임무를 완료하면 지정된 대기 위치로 복귀한다.

9. 프로젝트 주제 예시

다음과 같은 서비스가 가능합니다.

1) 학원 안내 로봇

방문자를 강의실, 사무실, 휴게공간 등 지정 위치로 안내합니다.

2) 사무실 순찰 로봇

정해진 경로를 순찰하면서 특정 객체나 상황을 YOLO로 확인합니다.

3) 실내 배송 로봇

출발점에서 물품을 받아 지정 위치까지 이동한 후 다시 대기 위치로 복귀합니다.

4) 시설물 점검 로봇

20층 내부의 특정 위치를 순찰하며 팀에서 학습한 객체를 검출합니다.

5) 분실물 탐색 로봇

복도를 순찰하면서 특정 물체를 YOLO로 검출합니다.

6) 스마트 안내·순찰 복합 로봇

정상 상태에서는 순찰하고 요청이 들어오면 지정 위치 안내 임무로 전환합니다.

프로젝트 범위가 12일이므로 여러 서비스를 억지로 합치는 것보다 하나의 명확한 서비스를 안정적으로 구현하는 것을 권장합니다.

10. YOLO는 반드시 서비스에 사용합니다

단순히 YOLO 화면에 Bounding Box가 출력되는 것은 프로젝트 서비스 통합으로 보기 어렵습니다.

객체 인식 결과가 실제 로봇의 판단에 사용되어야 합니다.

예를 들어 다음과 같습니다.

YOLO 객체 검출
       ↓
특정 객체 확인
       ↓
Mission Manager에 이벤트 전달
       ↓
로봇 행동 변경

적용 사례는 다음과 같습니다.

1) 사람 인식

사람 발견
 → 주행 속도 감소
 → 안전거리 유지

2) 표지판 인식

특정 표지판 발견
 → 지정된 Mission 실행

3) 물체 인식

배송 대상 물체 발견
 → 도착 확인
 → 음성 안내

4) 위험 객체 인식

위험 객체 검출
 → 정지
 → 음성 경고
 → 새로운 경로 요청

각 팀은 다른 팀과 차별화되는 팀 전용 객체 인식 주제를 선정하는 것을 권장합니다.

11. 지도는 반드시 팀이 직접 작성합니다

각 팀은 실제 LIMO를 이용해 직접 SLAM을 수행합니다.

다른 팀이 작성한 지도 파일을 받아 사용하는 것은 허용하지 않습니다.

권장 파일 구조는 다음과 같습니다.

team_navigation/
└── maps/
    ├── original/
    │   ├── map.pgm
    │   └── map.yaml
    │
    └── service/
        ├── map.pgm
        └── map.yaml

지도 작성 후 다음 과정을 수행합니다.

SLAM
 ↓
원본 지도 저장
 ↓
GIMP 편집
 ↓
노이즈 제거
 ↓
주행금지 영역 설정
 ↓
서비스용 지도 저장
 ↓
Localization 시험
 ↓
Nav2 주행 시험

원본 지도와 수정 지도를 모두 보관합니다.

12. Navigation2 파라미터를 직접 조정합니다

기본 Nav2 설정을 그대로 사용하는 것으로 끝내지 않습니다.

실제 20층 공간에서 반복 시험하고 파라미터를 조정합니다.

주요 확인 대상은 다음과 같습니다.

Robot Footprint
Inflation Radius
Cost Scaling Factor
Max Linear Velocity
Max Angular Velocity
Acceleration
Deceleration
Controller Frequency
Obstacle Range
Raytrace Range
Local Costmap
Global Costmap
Progress Checker
Goal Checker
xy_goal_tolerance
yaw_goal_tolerance
TF 관련 Timeout
Recovery Behavior

파라미터를 변경할 때는 반드시 기록을 남깁니다.

예:

항목:
xy_goal_tolerance

변경 전:
0.25 m

변경 후:
0.03 m

변경 목적:
목표점 도착 정밀도 향상

시험 횟수:
10회

평균 실제 오차:
2.6 cm

최대 오차:
3.8 cm

추가 조치:
저속 접근 구간 설정 필요

13. 20개 이상의 Waypoint를 정의합니다

최종 시스템에는 최소 20개의 경유점을 정의합니다.

예를 들어 다음과 같이 구성할 수 있습니다.

WP00 : 시작 위치
WP01 : 강의실 출입구
WP02 : 복도 진입점
WP03 : 복도 A
WP04 : 복도 B
WP05 : 휴게실 입구
WP06 : 휴게실
WP07 : 사무실 입구
WP08 : 사무실 A
WP09 : 사무실 B
...
WP20 : 복귀 위치

Waypoint에는 가능하면 이름을 부여합니다.

waypoints:
  home:
    x: 1.23
    y: 0.85
    yaw: 0.0

  classroom:
    x: 4.21
    y: -1.32
    yaw: 1.57

  office:
    x: 12.41
    y: 3.52
    yaw: 3.14

좌표만 나열하는 것보다 실제 서비스 위치 이름을 사용하는 것이 관리하기 좋습니다.

14. 4개 이상의 Trajectory를 정의합니다

Waypoint를 이용하여 최소 4개의 주행 경로를 구성합니다.

예를 들어 다음과 같습니다.

1) Trajectory 1 — 기본 순찰

HOME
 → WP01
 → WP03
 → WP05
 → WP08
 → HOME

2) Trajectory 2 — 사무실 안내

HOME
 → 강의실 출입구
 → 복도
 → 사무실
 → HOME

3) Trajectory 3 — 휴게공간 안내

HOME
 → 복도
 → 휴게공간
 → HOME

4) Trajectory 4 — 전체 순찰

HOME
 → 20층 주요 Waypoint
 → 전체 순찰
 → HOME

팀 서비스에 따라 배송, 순찰, 안내, 검색 등의 의미를 부여합니다.

15. Mission Manager를 구성하는 것을 권장합니다

여러 기능을 각각 실행하는 것보다 최종적으로 하나의 상태 머신으로 통합하는 것이 좋습니다.

예를 들어 다음과 같이 구성합니다.

BOOT
 ↓
SYSTEM_CHECK
 ↓
LOCALIZATION
 ↓
READY
 ↓
MISSION_START
 ↓
NAVIGATING
 ↓
OBJECT_DETECTION
 ↓
SERVICE_ACTION
 ↓
NEXT_WAYPOINT
 ↓
RETURN_HOME
 ↓
MISSION_COMPLETE

오류 상태도 반드시 고려합니다.

NORMAL
  │
  ├─ Obstacle
  ├─ Localization Lost
  ├─ Navigation Failed
  ├─ YOLO Error
  ├─ Sensor Error
  └─ Emergency Stop

프로젝트 완성도를 높이는 가장 중요한 프로그램 중 하나가 Mission Manager입니다.

16. 시스템 자동 실행

최종 프로젝트에서는 전원을 켠 후 매번 여러 개의 터미널을 열어 명령을 입력하는 방식을 피합니다.

예를 들어 다음 기능이 자동으로 실행되어야 합니다.

전원 ON
 ↓
Ubuntu 부팅
 ↓
ROS 2 환경 설정
 ↓
LIMO Bringup
 ↓
Sensor
 ↓
Camera
 ↓
Localization
 ↓
Nav2
 ↓
YOLO
 ↓
Mission Manager
 ↓
Audio
 ↓
READY

구현 방법은 팀이 결정할 수 있습니다.

예:

systemd
tmux
ROS 2 launch
Shell Script
PM2
위 방법들의 조합

가능하면 최종적으로 하나의 명령 또는 전원 인가만으로 전체 시스템을 실행할 수 있도록 구성합니다.

17. 시작 위치 초기화

로봇을 켤 때마다 RViz2에서 수동으로 2D Pose Estimate를 지정해야 한다면 자동 서비스 시스템으로 보기 어렵습니다.

프로젝트에서는 로봇을 항상 동일한 시작 위치에 놓는 것을 기본 조건으로 하고 시작 Pose를 설정하는 방법을 구현할 수 있습니다.

예:

전원 ON
 ↓
Localization 실행
 ↓
초기 Pose 설정
 ↓
Pose 안정화 확인
 ↓
READY

초기 위치가 제대로 설정되지 않았을 경우 임무를 시작하지 않도록 만드는 것도 좋은 방법입니다.

18. 요구사항과 설계 문서

이번 프로젝트에서는 프로그램뿐 아니라 다음 7개의 개발 문서를 작성합니다.

1) 사용자 요구사항 명세서

UR / URD
User Requirements / User Requirements Document

사용자가 로봇에 원하는 서비스를 정의합니다.

예:

UR-001
로봇은 사용자가 지정한 장소까지 자율주행해야 한다.

UR-002
로봇은 목표 위치에 도착하면 음성으로 안내해야 한다.

UR-003
로봇은 Wi-Fi가 끊겨도 현재 자율 임무를 수행해야 한다.

UR-004
로봇은 주행 중 장애물을 발견하면 충돌하지 않아야 한다.

UR-005
로봇은 팀에서 지정한 객체를 인식해야 한다.

2) 시스템 요구사항 명세서

SR
System Requirements

사용자 요구사항을 실제 시스템 요구사항으로 변환합니다.

예:

SR-001
시스템은 Navigation2를 이용하여 목표 위치까지 이동해야 한다.

SR-002
목표점 도착 위치 오차는 3cm 이내를 목표로 한다.

SR-003
시스템은 최소 20개의 Waypoint를 관리해야 한다.

SR-004
시스템은 최소 4개의 Trajectory를 실행할 수 있어야 한다.

SR-005
Wi-Fi 연결이 끊겨도 Jetson에서 Nav2와 Mission Manager가 동작해야 한다.

가능하면 다음과 같이 요구사항을 연결합니다.

UR-001 → SR-001
UR-001 → SR-002
UR-003 → SR-005

3) 시스템 아키텍처 문서

SA
System Architecture

하드웨어와 소프트웨어의 전체 구조를 작성합니다.

예:

다음 내용을 포함합니다.

하드웨어 구성도
ROS 2 노드 구성도
데이터 흐름도
TF Tree
Navigation 구조
Vision 구조
Mission 구조

4) 시스템/소프트웨어 설계서

SD
System Design / Software Design

전체 프로그램이 어떻게 동작하는지 설계합니다.

다음 내용을 작성합니다.

시스템 시작
초기화
Localization
Mission 시작
Waypoint 이동
YOLO 처리
장애물 처리
통신 단절 처리
임무 완료
복귀
오류 처리
시스템 종료

상태 머신 다이어그램을 포함하는 것을 권장합니다.

5) 상세설계 명세서

DS
Detailed Specification

핵심 ROS 2 노드의 상세 내용을 작성합니다.

예:

Node:
mission_manager

Input:
 /robot_pose
 /yolo/detections
 /mission_command

Output:
 /mission_status

Action Client:
 /navigate_to_pose

Parameters:
 waypoint_file
 retry_count
 goal_timeout

Main Functions:
 load_waypoints()
 start_mission()
 navigate()
 object_callback()
 goal_callback()
 recovery()

6) GUI/HMI 설계서

GUI/HMI를 구현하는 팀은 다음과 같은 내용을 설계할 수 있습니다.

시스템 상태
현재 Robot Pose
현재 Mission
현재 Waypoint
Nav2 상태
YOLO 객체
카메라 영상
배터리
시작
일시정지
취소
복귀
긴급정지
로그

GUI 구현 자체는 팀 프로젝트 시나리오와 개발 기간을 고려하여 범위를 결정합니다.

7) 인터페이스 명세서

IS
Interface Specification

ROS 2 Topic, Service, Action을 정리합니다.

ID	구분	이름	타입	송신	수신
IF-001	Topic	`/cmd_vel`	`geometry_msgs/Twist`	Nav2	LIMO
IF-002	Topic	`/scan`	`sensor_msgs/LaserScan`	LiDAR	Nav2
IF-003	Topic	Camera Image	`sensor_msgs/Image`	Camera	Vision
IF-004	Topic	Detection	Team-defined	YOLO	Mission
IF-005	Action	`navigate_to_pose`	Nav2 Action	Mission	Nav2

실제 사용되는 Topic 이름은 각 팀의 LIMO 환경에서 확인해서 작성합니다.

19. 문서 관리 방법

12일 프로젝트이므로 처음부터 모든 문서를 완벽하게 작성하려고 하지 않습니다.

GitHub의 docs 폴더에서 개발과 동시에 수정하는 것을 권장합니다.

docs/
├── 01_URD.md
├── 02_SR.md
├── 03_SA.md
├── 04_SD.md
├── 05_DS.md
├── 06_GUI_HMI.md
├── 07_IS.md
├── test/
└── images/

문서는 프로젝트가 변경되면 같이 변경되어야 합니다.

20. 12일 계획 요약표 예

일차	날짜	핵심 작업	완료 기준
DAY 1	9/3	주제·역할 선정	시나리오 확정
DAY 2	9/4	요구사항·설계	UR/SR/SA 초안
DAY 3	9/7	SLAM	팀 전용 지도
DAY 4	9/8	Localization/Nav2	단일 목표 주행
DAY 5	9/9	Nav2 튜닝	주행 정확도/정밀도
DAY 6	9/10	Waypoint/Trajectory	20 WP, 4 Trajectory
DAY 7	9/11	YOLO 학습	팀 전용 모델
DAY 8	9/14	YOLO ROS 2 연동	실제 로봇 Detection
DAY 9	9/15	Mission 통합	전체 서비스 1회 성공
DAY 10	9/16	자동화·통합시험	Wi-Fi OFF 포함
DAY 11	9/17	반복시험·문서	Release Candidate
DAY 12	9/18	최종 시연	프로젝트 발표

21. 팀원 역할 분담

4~5명 기준으로 다음과 같이 역할을 나누는 것을 권장합니다.

1) 프로젝트 리더

전체 일정 관리
요구사항 관리
GitHub 관리
개발 진척 관리
강사와 프로젝트 진행사항 공유
통합 일정 관리

2) Navigation 담당

SLAM
지도
Localization
Nav2
Waypoint
Trajectory
Nav2 튜닝

3) Vision / AI 담당

Camera
Dataset
Labeling
YOLO11
TensorRT
Detection ROS 2 Node

4) Mission / ROS 2 담당

Mission Manager
State Machine
Topic
Service
Action
시스템 통합

5) System / Test 담당

Bringup
자동 시작
로그
Wi-Fi 단절
시험
문서
발표자료

4명인 경우 역할을 일부 합칠 수 있습니다.

역할을 나누더라도 한 명만 전체 시스템을 알고 있는 구조는 피합니다.

모든 팀원은 전체 시스템을 실행하고 설명할 수 있어야 합니다.

22. 매일 팀장이 진행 현황을 보고합니다

팀장은 매일 작업 종료 전에 다음 내용을 정리하여 강사에게 공유합니다.

[팀명]
Unity

[날짜]
2026-09-08

[오늘 목표]
Nav2 단일 목표점 주행

[완료 내용]
1. Localization 완료
2. 단일 목표점 주행 성공
3. 서비스 지도 적용 완료

[미완료]
목표점 오차가 약 12cm 발생

[문제점]
고속 접근 시 최종 위치 오차 증가

[조치 내용]
max_vel_x 감소
Goal Checker 파라미터 검토

[내일 목표]
목표점 오차 3cm 수준 튜닝

[GitHub]
commit: abc1234

[강사 확인 필요]
xy_goal_tolerance와 실제 위치 오차 측정 방법 확인

“오늘 많이 진행했습니다.” 같은 보고는 사용하지 않습니다.

완료된 기능과 미완료 기능을 명확하게 구분합니다.

23. GitHub 작업 규칙

권장 Branch는 다음과 같습니다.

main
develop

feature/navigation
feature/vision
feature/mission
feature/automation
feature/audio
docs/requirements

원칙은 다음과 같습니다.

main에는 동작이 확인된 프로그램만 Merge합니다.
개발은 기능 Branch에서 수행합니다.
기능 완료 후 develop에 통합합니다.
다른 팀원이 작성한 코드를 Merge하기 전에 확인합니다.
로봇에서 직접 수정한 프로그램도 반드시 GitHub에 반영합니다.
매일 작업 종료 전에 Push합니다.
한 명의 Jetson 또는 노트북에만 최신 프로그램이 존재해서는 안 됩니다.
build, install, log 디렉터리는 Git에 등록하지 않습니다.

.gitignore 예:

build/
install/
log/
__pycache__/
*.pyc
.vscode/
.idea/

Commit 메시지는 가능한 한 기능을 알 수 있도록 작성합니다.

feat: add waypoint mission manager

feat: integrate yolo detection

fix: tune nav2 goal checker

fix: handle wifi disconnect

test: add waypoint accuracy result

docs: add system requirements

refactor: separate navigation and mission nodes

24. README에 반드시 포함할 내용

최종 README에는 최소한 다음 내용을 작성합니다.

프로젝트 소개
프로젝트 목적
서비스 시나리오
팀원 및 역할
하드웨어 구성
소프트웨어 구성
시스템 아키텍처
ROS 2 패키지 구조
Topic / Service / Action
설치 방법
Build 방법
실행 방법
자동 실행 방법
지도
Waypoint
Trajectory
YOLO 모델
Nav2 설정
시험 결과
알려진 문제
시연 영상

25. 반드시 수행해야 할 시험

최종 시연 전 다음 시험을 수행합니다(시험횟수는 팀별로 합리적인 값으로 변경 가능합니다).

ID	시험	권장 반복	목표
T-001	Localization	5회	정상 초기화
T-002	단일 목표점 이동	10회	반복 성공
T-003	목표점 정밀도	10회	목표 3cm 이내
T-004	통로 통과	5회	충돌 없이 통과
T-005	이동 장애물	5회	자연스러운 회피
T-006	두 로봇 교차	5회	충돌 없이 통과
T-007	20 Waypoint	3회 이상	전체 경로 완료
T-008	4 Trajectory	각 3회	정상 완료
T-009	YOLO 인식	반복 측정	성공률 기록
T-010	YOLO + 주행 연동	10회	지정 행동 수행
T-011	Wi-Fi OFF	5회	자율 임무 유지
T-012	전원 재인가	5회	자동 실행
T-013	Mission Cancel	5회	안전 정지
T-014	전체 서비스	10회	성공률 기록

시험 결과는 단순히 성공/실패만 작성하지 않습니다.

시험:
T-009 YOLO Object Detection

결과:
실패

환경:
복도 창가 역광

원인:
Detection confidence 감소

조치:
Dataset에 역광 이미지 추가
카메라 Exposure 조정

재시험:
성공

프로젝트에서 실패 기록은 감점 요소가 아닙니다.

원인을 분석하고 해결한 기록은 중요한 개발 결과입니다.

26. 프로젝트 최종 결과물

발표일까지 다음 자료를 GitHub에 준비합니다.

팀 전용 ROS 2 Workspace
팀 전용 ROS 2 Package
전체 프로그램
사용자 요구사항 명세서
시스템 요구사항 명세서
시스템 아키텍처 문서
시스템/소프트웨어 설계서
상세설계 명세서
GUI/HMI 설계서
인터페이스 명세서
SLAM 원본 지도
GIMP 편집 지도
Nav2 최종 파라미터
20개 이상 Waypoint
4개 이상 Trajectory
YOLO Dataset 정보
YOLO 학습 결과
YOLO 모델
ROS 2 YOLO Detection Node
Mission Manager
자동 실행 설정
Wi-Fi 단절 시험 결과
전체 통합 시험 결과
프로젝트 README
서비스 시연 영상
발표 자료

27. 최종 발표 권장 구성

발표는 소스 프로그램 설명이 중심이 되어서는 안 됩니다.

다음 순서로 구성하는 것을 권장합니다.

팀 소개
프로젝트 주제
서비스를 선정한 이유
실제 사용 시나리오
사용자 요구사항
시스템 요구사항
시스템 구성도
ROS 2 Node 구성
Topic / Service / Action
SLAM 지도
지도 편집 내용
Nav2 튜닝
Waypoint 20개
Trajectory 4개
YOLO Dataset
YOLO 학습 결과
ROS 2 YOLO 연동
Mission Manager
Wi-Fi 단절 대응
자동 실행
실제 서비스 시연
시험 결과
개발 과정에서 발생한 문제
해결 방법
향후 개선 방향

발표에서는 긴 소스코드를 보여주기보다는

시스템 구조, 알고리즘, 실제 로봇 동작, 시험 데이터, 실패 원인과 해결 과정

을 중심으로 설명합니다.

28. 평가 기준(안)

다음은 프로젝트 평가 기준의 한 가지 예입니다.

평가 항목	배점
서비스 시나리오 및 요구사항	10
시스템/소프트웨어 설계	10
SLAM 및 지도 완성도	10
Nav2 자율주행 및 파라미터 튜닝	15
20 Waypoint / 4 Trajectory	10
YOLO 학습 및 ROS 2 연동	10
자동 실행 및 Wi-Fi 단절 대응	5
전체 서비스 안정성 및 창의성	15
GitHub 협업 및 문서화	5
최종 발표 및 시연	10
합계	100

실제 평가 기준은 프로젝트 진행 상황에 따라 변경될 수 있습니다.

29. 수강생 주의사항

1) 첫날부터 코딩하지 마십시오.

서비스 시나리오와 요구사항을 먼저 확정하십시오.

2) 다른 팀의 지도를 사용하지 마십시오.

각 팀이 직접 SLAM하고 직접 편집합니다.

3) Nav2 기본 파라미터를 그대로 제출하지 마십시오.

실제 LIMO와 실제 주행 공간에서 시험하고 조정하십시오.

4) 숫자를 추측해서 작성하지 마십시오.

위치 오차, 성공률, 인식률 등은 실제 측정 결과를 사용하십시오.

5) 한 번 성공했다고 완료된 것이 아닙니다.

반복 시험을 수행하십시오.

6) YOLO Bounding Box만 출력해서는 안 됩니다.

객체 인식 결과가 로봇의 판단이나 행동에 사용되어야 합니다.

7) Wi-Fi 연결을 전제로 설계하지 마십시오.

핵심 프로그램은 LIMO 내부 Jetson에서 실행합니다.

8) 절대 경로 사용을 가능한 한 피하십시오.

예:

"/home/limo/team_ws/src/team_vision/models/best.engine"

보다는 ROS 2 패키지의 Share Directory를 이용하는 구조를 권장합니다.

9) 발표 전날 새로운 기능을 추가하지 마십시오.

9월 17일부터는 기능 추가보다 안정화와 시험에 집중합니다.

10) 로봇 속도를 지나치게 높이지 마십시오.

빠른 로봇보다 안전하고 정확한 로봇이 더 좋은 결과입니다.

11) 모든 팀원이 GitHub를 사용하십시오.

한 명이 모든 Commit을 대신하지 않습니다.

12) 모든 팀원이 전체 시스템 실행 방법을 알고 있어야 합니다.

담당 기능만 알고 전체 서비스를 모르는 상태는 피합니다.

13) 매일 실행 가능한 상태를 유지하십시오.

개발 중이더라도 develop 또는 안정 Branch에는 항상 실행 가능한 버전을 유지하는 것이 좋습니다.

14) Wi-Fi 없이 발표한다고 가정하고 준비하십시오.

지도, 모델, 음성, 설정, 프로그램이 모두 로봇 내부에서 실행 가능해야 합니다.

15) 안전을 최우선으로 합니다.

복도는 실제 사람이 사용하는 공간입니다.

사람이 접근하는 경우 무리하게 주행 시험을 계속하지 않습니다.

가능하면 주행중에 볼륨을 줄이고 안내 멘트를 출력하는 것도 방법입니다.

30. 프로젝트 중간 점검(권장)

각 팀들은 아래의 예와 같이 구체적인 점검 기준을 정하고 지정된 날에 해당 내용을 확인하면 프로젝트를 계획적으로 진행할 수 있습니다.

1) 9월 4일

[ ] 서비스 시나리오
[ ] 팀장 및 역할
[ ] URD
[ ] SR
[ ] 시스템 구조

2) 9월 8일

[ ] 팀 전용 지도
[ ] Localization
[ ] Nav2
[ ] 단일 목표점 주행

3) 9월 10일

[ ] Nav2 튜닝
[ ] 20 Waypoint
[ ] 4 Trajectory
[ ] Mission Manager 기본 구조

4) 9월 14일

[ ] YOLO 학습
[ ] YOLO ROS 2 적용
[ ] 실제 카메라 인식

5) 9월 16일

[ ] 전체 Mission 통합
[ ] 자동 실행
[ ] Wi-Fi OFF 시험
[ ] 두 로봇 교차 주행

6) 9월 17일

[ ] 기능 동결
[ ] 전체 반복 시험
[ ] 문서 완료
[ ] GitHub 완료
[ ] 발표자료
[ ] 시연 영상

31. 프로젝트 완료 기준(점검 기준)

다음 조건을 만족하면 프로젝트가 완료된 것으로 판단할 수 있습니다.

[ ] 전원을 켜면 로봇 시스템이 자동으로 실행된다.

[ ] 초기 위치가 정상적으로 설정된다.

[ ] 팀에서 직접 작성한 지도에서 Localization이 된다.

[ ] Nav2 자율주행이 가능하다.

[ ] 이동 장애물을 회피한다.

[ ] 두 로봇이 교차 주행할 수 있다.

[ ] 목표점 도착 오차를 실제로 측정하였다.

[ ] 목표점 도착 정밀도 3cm 이내를 목표로 튜닝하였다.

[ ] 최소 20개의 Waypoint가 정의되어 있다.

[ ] 20개 이상의 Waypoint를 실제 주행한다.

[ ] 최소 4개의 Trajectory가 정의되어 있다.

[ ] 4개 이상의 Trajectory를 실제 주행한다.

[ ] 팀 전용 YOLO Dataset이 있다.

[ ] 팀 전용 YOLO 모델이 있다.

[ ] 실제 LIMO에서 YOLO 객체 인식이 된다.

[ ] YOLO 결과가 실제 서비스 동작에 사용된다.

[ ] 효과음 또는 음성 안내가 동작한다.

[ ] Wi-Fi가 끊겨도 자율 임무가 수행된다.

[ ] Mission을 정상적으로 시작하고 종료할 수 있다.

[ ] 오류 발생 시 안전하게 처리한다.

[ ] 전체 서비스 시나리오가 반복 실행된다.

[ ] 요구사항 및 설계 문서가 작성되어 있다.

[ ] 모든 프로그램이 GitHub에 등록되어 있다.

[ ] README만 보고 다른 사람이 실행할 수 있다.

32. 마지막으로

이번 프로젝트의 목적은 예제 코드를 많이 만드는 것이 아닙니다.

지금까지 학습한

ROS 2, WEGO LIMO, SLAM, Navigation2, Camera, OpenCV, YOLO, TensorFlow, TensorRT

기술을 연결하여 실제 이동 로봇 서비스를 하나 완성하는 것이 목적입니다.

프로젝트 진행 순서는 다음 원칙을 지키는 것을 권장합니다.

요구사항
   ↓
설계
   ↓
작은 기능 구현
   ↓
개별 시험
   ↓
ROS 2 통합
   ↓
실제 로봇 시험
   ↓
반복 측정
   ↓
오류 수정
   ↓
최종 서비스

12일이라는 프로젝트 기간은 매우 짧습니다.

따라서 복잡한 기능을 계속 추가하기보다,

작은 서비스라도 처음부터 끝까지 안정적으로 실행되고, Wi-Fi가 끊겨도 스스로 임무를 수행하며, 실제 로봇에서 같은 결과를 반복해서 보여줄 수 있도록 만드는 것

을 가장 중요한 목표로 합니다.

프로젝트의 최종 결과는 단순한 ROS 2 예제가 아니라,

요구사항, 설계, 자율주행, 인공지능, 시스템 통합, 시험 및 검증 과정을 모두 경험하는 실제 ROS 2 이동 로봇 서비스 개발 결과물이 되어야 합니다.

각 팀들의 건투를 빕니다! 화이팅~~!!!