1. 프로젝트 개요
이번 프로젝트는 그동안 학습한 ROS 2 Humble, TurtleBot3 Burger, SLAM, Navigation2, 카메라 인식, 센서 연동, GUI, 자동 실행 기술을 하나의 서비스 로봇 시스템으로 통합하는 팀 프로젝트입니다.
단순히 로봇을 움직이는 수준이 아니라 실제 사용 가능한 이동 로봇 서비스를 기획하고, 요구사항 작성부터 설계, 구현, 시험, 발표까지 전체 개발 절차를 수행합니다.
- 프로젝트 주제: TurtleBot3 Burger를 이용한 ROS 2 이동 로봇 서비스 개발
- 프로젝트 기간: 2026년 7월 20일 월요일부터 2026년 8월 14일 금요일까지
- 프로젝트 기간: 총 4주
- 프로젝트 결과 발표: 2026년 8월 14일 금요일
- 개발 환경: Ubuntu 22.04 Server, ROS 2 Humble, TurtleBot3 Burger
- 카메라: Raspberry Pi Camera 2
- 개발 방식: 팀별 GitHub 저장소를 이용한 협업 개발
- 주요 기술: ROS 2, SLAM, Nav2, OpenCV, ArUco, 센서 브리지, PyQt, PM2, tmux
실습 공간은 강의실 내부에 구성된 장애물 주행 공간과 복도를 사용합니다. 일부 복도에서는 Wi-Fi 연결이 끊기므로 통신이 가능한 구역에서 서비스를 실행해야 합니다.
2. 프로젝트 목표
프로젝트의 최종 목표는 다음과 같습니다.
- 팀별 서비스 로봇 시나리오를 선정합니다.
- TurtleBot3 기본 패키지를 참고하여 팀 전용 ROS 2 패키지로 재구성합니다.
- 실제 로봇의 직진 거리와 회전 각도를 측정하고 오도메트리 오차를 보정합니다.
- 팀이 직접 주행 지역의 지도를 작성합니다.
- 작성한 지도에서 Navigation2 자율주행을 수행합니다.
- 10개 이상의 경유점과 2개 이상의 궤적을 정의합니다.
- 카메라, ArUco 마커, LiDAR, 외부 센서를 서비스에 통합합니다.
- 충전 스테이션 또는 지정 위치 정밀 파킹 기능을 구현합니다.
- 전원 인가 후 자동으로 실행되는 로봇 시스템을 구축합니다.
- Wi-Fi가 끊어진 상태에서도 로봇이 안전하게 임무를 수행하도록 구현합니다.
- 실제 측정 결과를 근거로 성능을 검증합니다.
- 요구사항, 설계, 인터페이스, GUI 문서를 작성합니다.
3. 팀별 GitHub 저장소
각 팀은 지정된 저장소를 사용합니다.
- Trillion 팀
https://github.com/unitydt-ros2-class2-2026/trillion_main_project_01.git - COM 팀
https://github.com/unitydt-ros2-class2-2026/com_main_project_01.git - YEYU 팀
https://github.com/unitydt-ros2-class2-2026/yeyu_main_project_01.git - AURIX 팀
https://github.com/unitydt-ros2-class2-2026/aurix_main_project_01.git - Nugul 팀
https://github.com/unitydt-ros2-class2-2026/nugul_main_project_01.git - ROS 팀
https://github.com/unitydt-ros2-class2-2026/ros_main_project_01.git - Gundam 팀
https://github.com/unitydt-ros2-class2-2026/gundam_main_project_01.git - SH 팀
https://github.com/unitydt-ros2-class2-2026/sh_main_project_01.git
저장소에는 프로그램 소스뿐만 아니라 요구사항 문서, 설계 문서, 지도, 파라미터, 측정 결과, 실행 방법을 함께 관리해야 합니다.
4. 팀별 ROS 2 작업공간과 패키지 구성
TurtleBot3 소스를 그대로 제출해서는 안 됩니다. TurtleBot3 소스를 참고하되 팀 이름이 포함된 작업공간과 패키지로 재구성해야 합니다.
COM 팀을 예로 들면 다음과 같이 구성할 수 있습니다.
com_ws/
└── src/
├── com_bringup/
├── com_navigation/
├── com_description/
├── com_interfaces/
├── com_sensors/
├── com_vision/
├── com_gui/
├── com_service/
└── com_launch/
각 패키지의 역할은 다음과 같습니다.
com_bringup: TurtleBot3 하드웨어와 기본 노드 실행com_navigation: SLAM, Localization, Nav2 설정com_description: URDF, Xacro, 센서 프레임 구성com_interfaces: 사용자 정의 메시지, 서비스, 액션com_sensors: Arduino 센서와 ROS 2 연결com_vision: 카메라, ArUco, 색상 인식, YOLO 처리com_gui: PyQt 기반 운영 GUIcom_service: 서비스 시나리오와 상태 머신com_launch: 전체 시스템 통합 실행
패키지를 지나치게 세분화할 필요는 없지만 하드웨어, 주행, 센서, 영상, 서비스 로직이 하나의 패키지에 무질서하게 섞이지 않도록 구성해야 합니다.
5. 필수 구현 요구사항
1) 로봇 이동 정밀도 측정
실제 로봇에 이동 명령을 전달한 후 줄자와 각도 측정 도구를 사용하여 이동 거리를 직접 측정해야 합니다.
- 직진 이동 오차는 1cm 이하를 목표로 합니다.
- 직진 1m 이동 시험을 10회 이상 수행합니다.
- 90도 회전 시험을 10회 이상 수행합니다.
- 180도 회전 시험을 10회 이상 수행합니다.
- 두 지점 사이 왕복 이동을 10회 이상 수행합니다.
- 측정 결과의 평균값, 최대 오차, 최소 오차, 반복도를 기록합니다.
wheel_radius와wheel_separation을 조정합니다.- 변경 전과 변경 후 결과를 비교합니다.
- 바닥 재질, 배터리 상태, 속도 조건을 기록합니다.
- 측정 결과를 CSV 또는 표로 관리합니다.
권장 측정 항목은 다음과 같습니다.
| 시험 번호 | 명령 거리 | 실제 거리 | 거리 오차 | 명령 각도 | 실제 각도 | 각도 오차 | 비고 |
|---|---|---|---|---|---|---|---|
| 1 | 1.00m | 0.99m | -0.01m | 90도 | 89도 | -1도 | 배터리 90% |
| 2 | 1.00m | 1.01m | 0.01m | 90도 | 91도 | 1도 | 동일 조건 |
측정값을 한 번만 얻고 성공으로 판단해서는 안 됩니다. 최소 10회 이상 반복하여 결과의 재현성을 확인해야 합니다.
2) 주행 지도 작성
각 팀은 실제 주행 공간을 직접 주행하면서 지도를 작성해야 합니다.
- 다른 팀이 작성한 지도는 사용할 수 없습니다.
- SLAM Toolbox 또는 Cartographer를 사용할 수 있습니다.
- 벽, 책상, 장애물 위치가 실제 공간과 일치해야 합니다.
- GIMP를 사용하여 불필요한 노이즈를 제거합니다.
- 주행금지 구역을 지도에 표시합니다.
- 로봇이 통과할 수 없는 공간을 명확히 막아야 합니다.
- 원본 지도와 편집 지도를 모두 보관합니다.
pgm,yaml파일을 GitHub에 등록합니다.- 수정한 지도에서 Localization과 Nav2를 다시 검증합니다.
지도 파일의 권장 구조는 다음과 같습니다.
team_navigation/
└── maps/
├── original_map.pgm
├── original_map.yaml
├── service_map.pgm
└── service_map.yaml
3) Navigation2 주행
작성한 지도를 적용하여 Navigation2를 실행해야 합니다.
- 시작 위치 초기화가 가능해야 합니다.
- 단일 목표점 주행이 가능해야 합니다.
- 10개 이상의 경유점을 정의해야 합니다.
- 2개 이상의 주행 궤적을 정의해야 합니다.
- 목표점 도착 위치 오차는 3cm 이내를 목표로 합니다.
- 좁은 통로를 통과할 수 있어야 합니다.
- 이동 장애물을 자연스럽게 회피해야 합니다.
- 다른 로봇과 교차하는 시험(공유기를 함께 사용하는 2팀이 진행)을 수행해야 합니다.
- 경로 막힘 상태에서 복구 동작을 수행해야 합니다.
- 목표 취소와 임무 중지 기능이 있어야 합니다.
다음과 같은 경로를 구성할 수 있습니다.
- 기본 순찰 경로: P1 → P2 → P3 → P4 → P1
- 배송 경로: 대기 위치 → 물품 수령 위치 → 배송 위치 → 대기 위치
- 환경 측정 경로: 측정 위치 1 → 측정 위치 2 → 측정 위치 3
- 충전 경로: 현재 위치 → 충전 대기점 → 정렬점 → 도킹점
- 긴급 복귀 경로: 현재 위치 → 안전 지점 → 시작 위치
4) Nav2 파라미터 조정
기본 파라미터를 그대로 사용하는 것이 아니라 실제 공간에 맞게 조정해야 합니다. 아래는 조정이 필요한 파라미터들입니다.
- 로봇 반경 또는 Footprint
- Inflation Radius
- Cost Scaling Factor
- Max Velocity
- Min Velocity
- Max Angular Velocity
- Goal Tolerance
- Controller Frequency
- Obstacle Range
- Raytrace Range
- Progress Checker
- Goal Checker
- Recovery Behavior
- Local Costmap 크기
- Global Costmap 업데이트 주기
최종 파라미터를 결정할 때는 변경 이유와 시험 결과를 기록해야 합니다.
변경 전
xy_goal_tolerance: 0.25
변경 후
xy_goal_tolerance: 0.03
변경 이유
목표점 정지 오차를 3cm 이내로 줄이기 위해 조정
시험 결과
10회 시험 평균 오차 2.4cm
5) 후진 안전 기능
로봇이 후진하는 동작이 포함된다면 후방 장애물을 감지해야 합니다.
- 후방 IR 센서를 설치하는 방법
- LiDAR 스캔 데이터의 후방 영역을 사용하는 방법
- 후방 장애물 감지 시 즉시 정지하는 방법
- 후진을 취소하고 새로운 경로를 요청하는 방법
후방 감지 범위의 예시는 다음과 같습니다.
후방 감지 각도: 150도에서 210도
경고 거리: 0.30m
정지 거리: 0.20m
6) 효과음과 음성 안내
로봇의 주요 상태는 효과음 또는 음성으로 안내해야 합니다.
- 시스템 시작
- 주행 준비 완료
- 임무 시작
- 목표점 도착
- 장애물 발견
- 임무 일시 정지
- 통신 끊김
- 충전 위치 도착
- 임무 완료
- 오류 발생
음성 출력이 주행 제어를 지연시키지 않도록 별도 노드를 사용하여 처리하는 것이 좋습니다.
7) 외부 센서 3개 이상 적용
Arduino 37종 센서 키트에 포함된 센서 중 3개 이상을 실제 서비스에 사용해야 합니다. 특히 1개의 입력 센서를 사용해야 합니다.
센서를 장착만 하고 값을 출력하는 것은 서비스 적용으로 인정하기 어렵습니다. 센서값이 로봇의 판단이나 동작에 사용되어야 합니다.
적용 예시는 다음과 같습니다.
- IR 장애물 센서: 후진 중 장애물 감지 및 정지
- DHT11 온습도 센서: 환경 측정 및 지정 위치별 데이터 저장
- 버튼 센서: 임무 시작, 일시 정지 또는 긴급 정지
- 3색 LED: 대기, 주행, 오류 상태 표시
- 릴레이 모듈: 조명, 팬 또는 외부 장치 제어
- 조도 센서: 어두운 구역에서 조명 자동 점등, 밤 인식
- 소리 센서: 특정 소리 감지 후 상태 보고
- 기울기 센서: 로봇 전도 또는 비정상 자세 감지
3색 LED와 릴레이를 각각 하나의 센서로 단순 계산하기보다는 실제 입력 센서를 2개 이상 포함하는 것이 좋습니다.
8) 충전 스테이션 파킹
충전 스테이션 또는 지정된 도킹 위치에 정밀하게 주차하는 기능을 구현해야 합니다.
권장 단계는 다음과 같습니다.
- Nav2를 사용하여 충전 스테이션 앞 대기점으로 이동합니다.
- 카메라로 ArUco 마커를 검출합니다.
- 마커 중심과 로봇 중심의 좌우 오차를 계산합니다.
- 마커까지의 거리를 계산합니다.
- 각도 오차를 줄이면서 저속으로 접근합니다.
- 최종 접근 구간에서는 Nav2가 아닌 직접 속도 제어를 사용합니다.
- 도킹 판단은 거리로 판단하거나 별도의 센서를 사용하여 판단할 수 있습니다.
- 로봇을 정지합니다.
- LED와 음성으로 파킹 완료를 알립니다.
- 실패하면 후퇴 후 재시도합니다.
권장 상태 머신은 다음과 같습니다.
IDLE
→ MOVE_TO_PRE_DOCK
→ SEARCH_ARUCO
→ ALIGN
→ APPROACH
→ DOCK_CHECK
→ DOCKED
9) 자동 실행 환경
로봇의 전원을 켠 후 SSH로 접속하여 여러 명령을 직접 실행하는 방식은 최종 결과물로 인정하기 어렵습니다.
- 전원 인가 후 ROS 2 환경을 자동으로 설정합니다.
- TurtleBot3 Bringup을 자동으로 실행합니다.
- 센서 노드를 자동으로 실행합니다.
- 카메라 노드를 자동으로 실행합니다.
- 서비스 노드를 자동으로 실행합니다.
- 상태 관리 노드를 자동으로 실행합니다.
- 시작 위치를 초기화합니다.
- 노드가 종료되면 자동으로 재시작합니다.
- 실행 로그를 파일로 저장합니다.
- PM2 또는 tmux를 이용하여 상태를 확인할 수 있어야 합니다.
PM2 프로세스 구성 예시는 다음과 같습니다.
team_bringup
team_sensor_bridge
team_camera
team_aruco
team_navigation
team_service_manager
team_voice
team_status
10) 카메라와 ArUco 응용
ArUco 마커는 반드시 사용해야 합니다.
다음과 같은 기능으로 적용할 수 있습니다.
- 충전 스테이션 위치 인식
- 배송 위치 식별
- 방 번호 또는 구역 번호 인식
- 특정 마커에서 임무 변경
- 출발 위치 자동 확인
- 정밀 파킹
- 물품 수령 위치 확인
- 마커별 음성 안내
ArUco 이외에 카메라 응용 기능을 하나 더 구현하는 것이 안전합니다.
- 사람 검출
- 색상 물체 추적
- 물품 유무 확인
- 특정 객체 검출
- 라인 검출
6. Wi-Fi가 끊기는 공간에 대한 설계 기준
복도에서는 Wi-Fi가 끊길 수 있으므로 로봇의 핵심 기능을 원격 PC에서 실행해서는 안 됩니다.
- 주행 판단은 TurtleBot3 내부 컴퓨터에서 실행합니다.
- Nav2는 로봇에서 실행합니다. 단 rviz2는 원격 PC에서 실행할 수 있습니다.
- 카메라 인식은 가능한 한 로봇에서 실행합니다. 이미지 출력은 원격 PC에서 실행합니다.
- 경유점과 지도는 로봇 내부에 저장합니다.
- 음성 출력도 로봇 내부에서 실행합니다.
- 원격 PC의 PyQt GUI는 명령과 모니터링 용도로만 사용합니다.
- 임무 시작 후 Wi-Fi가 끊겨도 정해진 임무를 수행할 수 있어야 합니다.
- 통신이 끊겼을 때의 동작을 요구사항에 명시해야 합니다.
- 로봇 로그는 로봇 내부에 저장한 후 연결 복구 시 확인합니다.
통신 끊김 처리 방식은 다음 중 하나를 팀이 결정해야 합니다.
- 자율 임무가 시작된 상태라면 임무를 계속 수행합니다.
- 원격 수동 조작 상태라면 즉시 정지합니다.
- 위험 구역이라면 안전 위치로 이동 후 정지합니다.
- 일정 시간 통신이 복구되지 않으면 시작 위치로 복귀합니다.
어떤 방식을 선택하든 요구사항 문서와 상태 머신에 명확히 기록해야 합니다.
7. 서비스 시나리오 작성
1) 서비스 시나리오란?
서비스 시나리오는 로봇이 누구를 위해, 어떤 장소에서, 어떤 문제를 해결하고, 어떤 순서로 동작하는지를 정리한 문서입니다.
단순히 다음과 같이 기술 목록을 작성하는 것은 서비스 시나리오가 아닙니다.
- Nav2를 사용한다.
- ArUco 마커를 인식한다.
- 센서 3개를 사용한다.
- PyQt GUI를 만든다.
서비스 시나리오는 다음과 같이 실제 로봇의 동작 순서로 작성해야 합니다.
- 사용자가 GUI에서 임무를 선택한다.
- 로봇이 시스템과 센서 상태를 확인한다.
- 지정된 경유점으로 이동한다.
- 카메라와 센서를 이용해 작업을 수행한다.
- 임무를 완료한 후 충전 위치로 복귀한다.
2) 시나리오 작성 전에 확인할 사항
프로젝트 기간은 4주이므로 실현 가능한 범위를 정해야 합니다.
- 기존 강의에서 학습한 기술을 중심으로 구성합니다.
- 새로운 핵심 기술은 1개 정도만 추가합니다.
- TurtleBot3 Burger의 크기와 성능을 고려합니다.
- 강의실과 주행 공간에서 반복 시험할 수 있어야 합니다.
- 인터넷과 Wi-Fi 연결 없이도 핵심 기능이 동작해야 합니다.
- 발표 당일 재현 가능한 시나리오를 선택합니다.
3) 서비스 시나리오 필수 항목
각 팀의 시나리오에는 다음 내용을 포함해야 합니다.
- 시나리오 이름
- 서비스 목적
- 주요 사용자
- 서비스 장소
- 사전 조건
- 시작 조건
- 정상 동작 순서
- 예외 상황 처리
- 종료 조건
- 사용 센서
- 카메라와 ArUco 활용 방법
- 경유점과 Trajectory 구성
- 음성 및 효과음
- GUI 기능
- 안전 기능
- 성능 목표와 시험 방법
4) 서비스 목적을 먼저 정합니다
서비스 목적은 기술 이름이 아니라 해결하려는 문제를 기준으로 작성해야 합니다.
좋은 예시는 다음과 같습니다.
- 강의실의 환경 정보를 자동으로 측정하는 순찰 로봇
- 지정된 장소로 소형 물품을 전달하는 배송 로봇
- 방문자를 목적지까지 안내하는 안내 로봇
- 시설 이상 상태를 확인하는 안전 점검 로봇
- 물품을 회수하여 지정 장소로 이동하는 회수 로봇
“YOLO와 Nav2를 사용하는 로봇”과 같은 표현은 서비스 목적이 아닙니다.
5) 정상 시나리오 작성 방법
정상 시나리오는 임무 시작부터 완료까지 시간 순서대로 작성합니다.
예시는 다음과 같습니다.
- 로봇 전원을 켭니다.
- PM2가 필요한 ROS 2 노드를 자동 실행합니다.
- 로봇의 초기 위치를 설정합니다.
- 사용자가 GUI에서 임무를 선택합니다.
- 로봇이 음성으로 임무 시작을 안내합니다.
- 등록된 경유점을 순서대로 이동합니다.
- 각 위치에서 센서 측정 또는 카메라 인식을 수행합니다.
- 측정 결과와 위치 정보를 저장합니다.
- 모든 경유점 작업을 완료합니다.
- 충전 스테이션 앞까지 이동합니다.
- ArUco 마커를 이용해 정렬하고 파킹합니다.
- 음성으로 임무 완료를 안내합니다.
6) 예외 시나리오를 반드시 작성합니다
실제 로봇은 항상 정상적으로 동작하지 않습니다. 다음 상황을 반드시 고려해야 합니다.
- 장애물로 경로가 막힌 경우
- 다른 로봇과 마주친 경우
- Wi-Fi 연결이 끊긴 경우
- 센서 데이터가 수신되지 않는 경우
- 카메라 영상이 끊긴 경우
- ArUco 마커를 찾지 못한 경우
- 목표점에 도착하지 못한 경우
- 로봇이 현재 위치를 잃은 경우
- 파킹에 실패한 경우
- 사용자가 임무를 취소한 경우
- 긴급 정지 버튼이 눌린 경우
- ROS 2 노드가 비정상 종료된 경우
예외 상황에는 대기 시간, 재시도 횟수, 정지 조건을 명확히 작성해야 합니다.
7) 모호한 표현을 피합니다
다음과 같은 표현은 사용하지 않는 것이 좋습니다.
- 적절하게 회피한다.
- 정확하게 도착한다.
- 빠르게 인식한다.
- 상황에 맞게 정지한다.
- 자동으로 복구한다.
대신 수치와 조건을 사용합니다.
- 장애물이 20cm 이내이면 정지한다.
- 목표점에서 3cm 이내에 정지한다.
- 마커를 5초 동안 찾지 못하면 재탐색한다.
- 파킹 실패 시 최대 3회 재시도한다.
- 센서 데이터가 2초 이상 없으면 오류로 판단한다.
8) 센서와 카메라는 서비스 판단에 사용
센서는 단순히 값을 출력하는 용도로 사용해서는 안 됩니다.
예시는 다음과 같습니다.
- DHT11: 온도와 습도 측정
- 조도 센서: 어두운 구역 감지
- IR 센서: 후진 중 장애물 감지
- 버튼: 임무 시작 또는 긴급 정지
- 3색 LED: 대기, 주행, 오류 상태 표시
ArUco 마커도 단순 검출이 아니라 다음과 같은 동작에 사용해야 합니다.
- 목적지 확인
- 배송 위치 식별
- 경유점 구역 확인
- 충전 스테이션 위치 확인
- 정밀 파킹
- 마커 ID에 따른 임무 변경
9) Wi-Fi 단절을 고려해야 합니다
복도에서 Wi-Fi가 끊길 수 있으므로 핵심 기능은 로봇에서 실행해야 합니다.
- TurtleBot3 Bringup
- Navigation2
- 서비스 상태 머신
- 센서 처리
- 카메라 처리
- 음성 안내
- 로그 저장
- 안전 정지
원격 PC의 GUI는 임무 시작, 취소, 상태 확인 용도로만 사용하는 것이 좋습니다.
Wi-Fi가 끊겼을 때 로봇이 다음 중 어떤 동작을 할지도 미리 정해야 합니다.
- 현재 자율 임무를 계속한다.
- 안전하게 정지한다.
- 가까운 안전 위치로 이동한다.
- 시작 위치로 복귀한다.
10) 4주 안에 구현 가능한 시나리오 예시
[ 환경 순찰 로봇 ]
- 10개 이상의 경유점을 순찰합니다.
- 온도, 습도, 조도를 측정합니다.
- ArUco 마커로 위치를 확인합니다.
- 이상 상태를 LED와 음성으로 알립니다.
- 순찰 완료 후 충전 위치에 파킹합니다.
[소형 물품 배송 로봇]
- 사용자가 배송 위치를 선택합니다.
- 물품 적재 버튼을 확인합니다.
- Nav2로 배송 위치까지 이동합니다.
- ArUco 마커로 목적지를 확인합니다.
- 배송 완료 음성을 출력합니다.
- 충전 위치로 복귀합니다.
※ 물품 배송할 공간이 없기 때문에 가상의 물품을 운반하는 것으로 대체 하는 것 고려
[방문자 안내 로봇]
- GUI에서 목적지를 선택합니다.
- 로봇이 음성으로 출발을 안내합니다.
- 지정된 경로를 따라 이동합니다.
- 위치별 안내 음성을 출력합니다.
- 안내 완료 후 시작 위치로 복귀합니다.
[시설 안전 점검 로봇]
- 지정된 위치를 순찰합니다.
- 온도와 환경 센서를 측정합니다.
- 카메라로 특정 객체를 확인합니다.
- 이상 상태를 기록하고 경고합니다.
- 임무 완료 후 충전 위치로 이동합니다.
11) 피해야 할 시나리오
다음과 같은 시나리오는 4주 프로젝트 범위를 초과할 가능성이 높습니다.
- 건물 전체 배송
- 엘리베이터 연동
- 자동문 제어
- 자유로운 음성 대화
- 얼굴 인식 기반 개인 서비스
- 다수 로봇의 자동 업무 분배
- 로봇팔 자동 적재
- 실제 자동 충전 단자 연결
- 클라우드와 모바일 앱 동시 개발
- 외부 인터넷에 의존하는 서비스
큰 기능은 단순화할 수 있습니다.
예를 들어 실제 자동 충전 대신 ArUco 마커를 이용한 충전 위치 파킹까지만 구현할 수 있습니다.
12) 시나리오 검토 기준
시나리오를 확정하기 전에 다음 내용을 확인합니다.
- 서비스 사용자와 목적이 명확한가?
- 로봇의 시작 조건과 종료 조건이 있는가?
- 정상 동작 순서가 구체적인가?
- 장애물과 센서 오류 처리가 있는가?
- Wi-Fi가 끊겨도 안전하게 동작하는가?
- 센서 3개가 실제 판단에 사용되는가?
- ArUco 마커가 서비스 동작에 사용되는가?
- 경유점 10개 이상을 자연스럽게 사용할 수 있는가?
- Trajectory 2개 이상을 정의할 수 있는가?
- 음성과 효과음이 상태에 맞게 사용되는가?
- 긴급 정지 방법이 있는가?
- 전체 시나리오를 10회 이상 반복 시험할 수 있는가?
- 성공과 실패를 수치로 판단할 수 있는가?
- 전원 인가 후 자동 실행되는가?
- 4주 안에 구현 가능한가?
13) 최종 작성 원칙
- 강의에서 배운 지식을 구현할 수 있는 서비스를 고려합니다.
- 사용자와 장소를 구체적으로 작성합니다.
- 시작부터 종료까지 시간 순서대로 작성합니다.
- 정상 상황과 예외 상황을 함께 작성합니다.
- 센서와 카메라가 실제 판단에 사용되도록 합니다.
- 수치와 조건을 이용해 동작을 정의합니다.
- Wi-Fi와 원격 PC에 의존하지 않도록 설계합니다.
- 기능 수보다 안정성과 반복 성공률을 우선합니다.
- 발표 당일 재현 가능한 시나리오를 선택합니다.
- 4주 동안 완성할 수 있는 범위로 제한합니다.
좋은 서비스 시나리오는 기능이 많은 시나리오가 아닙니다. 실제 로봇에서 처음부터 끝까지 안정적으로 실행되고, 문제가 발생했을 때 안전하게 대응하며, 같은 결과를 반복해서 보여줄 수 있는 시나리오입니다.
[ 시나리오 작성 사례 ]
8. 제출해야 할 요구사항 및 설계 문서
각 팀은 다음 7개의 문서를 작성해야 합니다.
1) 사용자 요구사항 명세서
사용자가 로봇에 원하는 기능을 정의합니다.
포함 내용은 다음과 같습니다.
- 서비스 목적
- 사용자 유형
- 사용 환경
- 주요 서비스 시나리오
- 사용자 기능 요구사항
- 안전 요구사항
- 성능 요구사항
- 제한 조건
- 정상 시나리오
- 예외 시나리오
요구사항에는 식별 번호를 부여합니다.
UR-001 로봇은 사용자가 지정한 위치로 자율주행해야 한다.
UR-002 로봇은 목표점 도착 시 음성으로 안내해야 한다.
UR-003 로봇은 통신이 끊겨도 안전하게 정지하거나 임무를 계속해야 한다.
2) 시스템 요구사항 명세서
사용자 요구사항을 구현하기 위한 시스템 수준의 요구사항을 정의합니다.
SR-001 시스템은 Nav2를 이용하여 목표점까지 자율주행해야 한다.
SR-002 목표점 도착 위치 오차는 3cm 이내여야 한다.
SR-003 로봇은 20cm 이내의 후방 장애물을 감지하면 정지해야 한다.
각 시스템 요구사항은 관련 사용자 요구사항과 연결해야 합니다.
3) 시스템 아키텍처 문서
시스템을 구성하는 하드웨어와 소프트웨어 구조를 작성합니다.
- TurtleBot3 Burger
- OpenCR
- LiDAR
- Raspberry Pi Camera 2
- Arduino 센서 보드
- ROS 2 노드
- Nav2
- PyQt GUI
- PM2 또는 tmux
- 토픽, 서비스, 액션 연결 구조
아키텍처 문서에는 노드 구성도와 데이터 흐름도를 포함해야 합니다.
4) 시스템 또는 소프트웨어 설계서
서비스가 동작하는 전체 로직을 설계합니다.
- 시스템 시작 과정
- 초기 위치 설정
- 임무 선택
- 경유점 이동
- 센서 처리
- 카메라 처리
- 장애물 대응
- 충전 스테이션 복귀
- 오류 처리
- 시스템 종료
상태 머신 다이어그램을 포함하는 것이 좋습니다.
5) 상세설계 명세서
각 노드와 클래스, 함수 수준의 상세 내용을 작성합니다.
- 노드 이름
- 노드 기능
- 입력 토픽
- 출력 토픽
- 서비스
- 액션
- 파라미터
- 타이머 주기
- 클래스 구성
- 주요 함수
- 예외 처리
- 종료 조건
6) GUI 또는 HMI 설계서
PyQt GUI 화면과 기능을 설계합니다.
권장 화면 구성은 다음과 같습니다.
- 로봇 연결 상태
- 현재 위치
- 배터리 상태
- 센서값
- 카메라 영상
- 임무 선택
- 경유점 선택
- 임무 시작
- 일시 정지
- 임무 취소
- 긴급 정지
- 로그 출력
- 충전 복귀
- 오류 메시지
7) 인터페이스 명세서
ROS 2 통신 인터페이스를 정리합니다.
| ID | 구분 | 이름 | 메시지 타입 | 송신 노드 | 수신 노드 | 주기 |
|---|---|---|---|---|---|---|
| IF-001 | Topic | /cmd_vel | geometry_msgs/Twist | Navigation | Base | 필요 시 |
| IF-002 | Topic | /scan | sensor_msgs/LaserScan | LiDAR | Nav2 | 10Hz |
| IF-003 | Topic | /camera/image_raw | sensor_msgs/Image | Camera | Vision | 30Hz |
| IF-004 | Service | /start_mission | 사용자 정의 | GUI | Mission Manager | 요청 시 |
| IF-005 | Action | /navigate_to_pose | NavigateToPose | Mission Manager | Nav2 | 요청 시 |
9. 4주 프로젝트 진행 계획
각 팀별로 4주 프로벡트 진행 계획을 수립하고 내용을 정리해서 Github에 업로드 합니다. 실현 가능한 내용으로 작성해 주세요. 아래에 정리한 내용은 참고하시기 바랍니다.
개발 계획은 일별로 구체적인 목표가 포함되어야 합니다.
1) 1주차 계획: 요구사항 정의와 기본 시스템 구축
기간은 2026년 7월 20일부터 7월 24일까지입니다.
목표는 서비스 시나리오를 확정하고 팀 전용 ROS 2 작업공간을 구축하는 것입니다.
| 날짜 | 주요 작업 | 결과물 |
|---|---|---|
| 7월 20일 | 프로젝트 설명, 역할 분담, 서비스 아이디어 선정 | 프로젝트 주제, 팀 역할표 |
| 7월 21일 | 사용자 요구사항과 시스템 요구사항 작성 | URD 초안, SR 초안 |
| 7월 22일 | 팀 작업공간과 패키지 재구성 | 팀 전용 ROS 2 패키지 |
| 7월 23일 | TurtleBot3 Bringup, 카메라, 센서 기본 연결 | 하드웨어 실행 확인 |
| 7월 24일 | 직진·회전 정밀도 측정 시작 | 1차 측정표, 파라미터 초깃값 |
1주차 완료 기준은 다음과 같습니다.
- 서비스 시나리오가 확정되어야 합니다.
- 팀원별 담당 업무가 결정되어야 합니다.
- 팀 전용 작업공간이 빌드되어야 합니다.
- GitHub에서 모든 팀원이 Commit과 Pull을 할 수 있어야 합니다.
- TurtleBot3 Bringup이 정상 실행되어야 합니다.
- 카메라와 센서 토픽을 확인해야 합니다.
- URD와 SR 초안이 작성되어야 합니다.
2) 2주차 계획: 지도 작성과 핵심 기능 개발
기간은 2026년 7월 27일부터 7월 31일까지입니다.
목표는 실제 주행 지도를 작성하고 Nav2, 센서, 카메라 기능을 개별적으로 완성하는 것입니다.
| 날짜 | 주요 작업 | 결과물 |
|---|---|---|
| 7월 27일 | SLAM을 이용한 팀별 지도 작성 | 원본 지도 |
| 7월 28일 | GIMP 지도 편집, 주행금지 구역 설정 | 최종 지도 |
| 7월 29일 | Nav2 실행, 단일 목표점 주행 시험 | Nav2 기본 파라미터 |
| 7월 30일 | 센서 3개 연동, 카메라 응용 개발 | 센서 및 영상 노드 |
| 7월 31일 | ArUco 검출과 경유점 주행 통합 | ArUco 기능, 경유점 파일 |
2주차 완료 기준은 다음과 같습니다.
- 팀이 직접 작성한 지도가 있어야 합니다.
- 지도에서 Localization이 가능해야 합니다.
- 단일 목표점 주행이 가능해야 합니다.
- 센서 3개 이상의 토픽이 발행되어야 합니다.
- ArUco 마커가 검출되어야 합니다.
- 최소 5개 이상의 경유점을 시험해야 합니다.
- 시스템 아키텍처 문서가 작성되어야 합니다.
3) 3주차 계획: 서비스 통합과 자동화
기간은 2026년 8월 3일부터 8월 7일까지입니다.
목표는 개별 기능을 하나의 서비스 상태 머신으로 통합하는 것입니다.
| 날짜 | 주요 작업 | 결과물 |
|---|---|---|
| 8월 3일 | 서비스 상태 머신 구현 | Mission Manager |
| 8월 4일 | 10개 경유점, 2개 Trajectory 구현 | 주행 경로 파일 |
| 8월 5일 | 충전 스테이션 파킹과 ArUco 정렬 | 파킹 기능 |
| 8월 6일 | 음성, 효과음, LED, GUI 통합 | 사용자 인터페이스 |
| 8월 7일 | PM2·tmux 자동 실행 및 통신 단절 시험 | 자동 실행 환경 |
3주차 완료 기준은 다음과 같습니다.
- 서비스 시나리오가 처음부터 끝까지 한 번 이상 실행되어야 합니다.
- 10개 이상의 경유점이 정의되어야 합니다.
- 2개 이상의 Trajectory가 정의되어야 합니다.
- 충전 스테이션 파킹이 동작해야 합니다.
- 음성 또는 효과음이 상태에 따라 출력되어야 합니다.
- 전원 인가 후 자동 실행되어야 합니다.
- Wi-Fi가 끊겨도 안전하게 동작해야 합니다.
- GUI에서 시작, 정지, 취소가 가능해야 합니다.
4) 4주차 계획: 성능 개선, 검증, 문서화 및 발표
기간은 2026년 8월 10일부터 8월 14일까지입니다.
목표는 기능 추가보다 안정성 확보와 정량적 검증에 집중하는 것입니다.
| 날짜 | 주요 작업 | 결과물 |
|---|---|---|
| 8월 10일 | 직진, 회전, 목표점 도착 오차 최종 측정 | 최종 성능 측정표 |
| 8월 11일 | 좁은 통로와 이동 장애물 회피 시험 | Nav2 최종 파라미터 |
| 8월 12일 | 두 로봇 교차 주행과 예외 상황 시험 | 통합 시험 결과서 |
| 8월 13일 | 문서, GitHub, 발표 자료, 영상 정리 | 최종 제출 자료 |
| 8월 14일 | 최종 시연 및 결과 발표 | 프로젝트 발표 |
4주차에는 새로운 기능을 무리하게 추가하지 않는 것이 중요합니다. 기능이 많아도 시연 중 멈추면 완성도가 낮게 평가됩니다.
10. 팀원 역할 분담 예시
팀원 수에 따라 한 명이 여러 역할을 담당할 수 있습니다.
- 프로젝트 리더
일정 관리, GitHub 관리, 요구사항 관리, 통합 진행 - Navigation 담당
SLAM, 지도 편집, Localization, Nav2 파라미터 조정 - 로봇 제어 담당
오도메트리 분석, 이동 정밀도 측정, 속도 제어, 후진 안전 - 비전 담당
카메라, OpenCV, ArUco, 색상 인식 또는 YOLO - 센서 담당
Arduino 센서 브리지, 센서 데이터 처리, LED와 릴레이 - GUI 담당
PyQt 화면, 상태 표시, 임무 제어, 오류 메시지 - 시스템 담당
PM2, tmux, 자동 시작, 로그 관리, 네트워크 단절 처리 - 문서 및 시험 담당
요구사항, 설계서, 시험 결과, 발표 자료, 시연 영상
역할을 분담하더라도 본인이 작성한 기능만 알고 다른 기능을 전혀 모르는 상태가 되어서는 안 됩니다. 모든 팀원은 전체 실행 방법과 서비스 흐름을 설명할 수 있어야 합니다.
11. GitHub 작업 규칙
1) 브랜치 구성
main
develop
feature/navigation
feature/vision
feature/sensor
feature/gui
feature/mission
feature/automation
main브랜치에는 동작이 확인된 소스만 병합합니다.- 개발은
develop또는 기능 브랜치에서 진행합니다. - 기능 구현 후 다른 팀원이 검토하고 병합합니다.
- 로봇에서 직접 수정한 소스를 반드시 GitHub에 반영합니다.
- 빌드 파일은 저장소에 등록하지 않습니다.
.gitignore에는 다음 내용을 포함합니다.
build/
install/
log/
__pycache__/
*.pyc
.vscode/
.idea/
2) Commit 메시지 예시
feat: add ArUco docking controller
fix: correct wheel separation parameter
docs: add system requirement document
test: add waypoint repeatability result
refactor: separate navigation and mission nodes
3) README 필수 내용
- 프로젝트 소개
- 서비스 시나리오
- 하드웨어 구성
- 소프트웨어 구성
- 패키지 구조
- 설치 방법
- 빌드 방법
- 실행 방법
- 자동 실행 방법
- 토픽, 서비스, 액션 목록
- 지도와 경유점 설명
- 시험 결과
- 알려진 문제
- 팀원 역할
12. 시험 항목
최종 시연 전에 다음 시험을 수행해야 합니다. 횟수는 탄력적으로 수정 가능합니다.
| 시험 ID | 시험 내용 | 반복 횟수 | 목표 |
|---|---|---|---|
| T-001 | 1m 직진 | 10회 | 오차 1cm 이하 |
| T-002 | 90도 회전 | 10회 | 각도 오차 최소화 |
| T-003 | 두 지점 왕복 | 10회 | 반복도 확인 |
| T-004 | 목표점 도착 | 10회 | 위치 오차 3cm 이내 |
| T-005 | 좁은 통로 통과 | 5회 | 충돌 없이 통과 |
| T-006 | 이동 장애물 회피 | 5회 | 자연스러운 재경로 생성 |
| T-007 | 두 로봇 교차 | 5회 | 충돌 없이 통과 |
| T-008 | 후방 장애물 감지 | 10회 | 정지 성공률 100% |
| T-009 | ArUco 인식 | 20회 | 인식 성공률 기록 |
| T-010 | 충전 위치 파킹 | 10회 | 성공률과 오차 기록 |
| T-011 | Wi-Fi 연결 해제 | 5회 | 정의된 안전 동작 수행 |
| T-012 | 노드 비정상 종료 | 5회 | 자동 재시작 확인 |
| T-013 | 전원 재인가 | 5회 | 자동 실행 확인 |
| T-014 | 전체 서비스 시나리오 | 10회 | 성공률 기록 |
시험 결과는 성공과 실패만 기록하지 말고 실패 원인도 작성해야 합니다.
시험 결과: 실패
원인: ArUco 마커가 창문 역광으로 검출되지 않음
조치: 마커 위치 변경, 카메라 노출값 고정
재시험 결과: 성공
13. 프로젝트 결과물
최종 발표일까지 다음 결과물을 준비해야 합니다.
- 팀 전용 ROS 2 작업공간
- 팀 전용 ROS 2 패키지
- 전체 소스가 등록된 GitHub 저장소
- 사용자 요구사항 명세서
- 시스템 요구사항 명세서
- 시스템 아키텍처 문서
- 시스템 또는 소프트웨어 설계서
상세설계 명세서(강사와 제출 협의)- GUI 또는 HMI 설계서
- 인터페이스 명세서
- 원본 지도와 편집 지도
- Nav2 최종 파라미터
- 10개 이상의 경유점
- 2개 이상의 Trajectory
- 이동 정밀도 측정 결과
- 통합 시험 결과
- 자동 실행 설정 파일
- 서비스 시연 영상
- 발표 자료(ppt)
- 실행 방법이 포함된 README
14. 최종 발표 구성
발표 시간에 맞추어 다음 순서로 준비합니다. 아래의 목차는 작성사례입니다. 팀별로 필요한 내용을 첨삭할 수 있습니다.
- 팀 소개
- 프로젝트 주제
- 서비스가 필요한 이유
- 사용자 요구사항
- 시스템 요구사항
- 시스템 구성도
- ROS 2 노드 구성
- 주요 토픽, 서비스, 액션
- 지도 작성 결과
- 오도메트리 보정 결과
- Nav2 파라미터 조정 결과
- 카메라와 ArUco 기능
- 센서 3개 적용 내용
- 충전 스테이션 파킹
- 자동 실행 구조
- 통신 단절 대응
- 실제 로봇 시연
- 시험 결과
- 문제점과 해결 과정
- 향후 개선 계획
발표에서는 소스 코드를 길게 보여주기보다 시스템 구조, 구현 결과, 측정 데이터, 문제 해결 과정을 중심으로 설명해야 합니다.
15. 평가 기준 예시
아래의 평가 기준은 평가안입니다. 추후 평가위원들과 상의하여 수정할 수 있습니다. 수정한 내용이 있으면 즉시 공지하도록 하겠습니다.
| 평가 항목 | 배점 |
|---|---|
| 서비스 시나리오와 요구사항 | 10점 |
| 팀 전용 패키지 구성 | 10점 |
| 이동 정밀도와 오도메트리 보정 | 10점 |
| 지도 작성과 Nav2 주행 | 15점 |
| 경유점과 Trajectory | 10점 |
| 카메라와 ArUco 응용 | 10점 |
| 센서 3개 이상 적용 | 10점 |
| 충전 스테이션 파킹 | 10점 |
| 자동 실행과 통신 단절 대응 | 5점 |
| 문서, GitHub, 발표 완성도 | 10점 |
| 합계 | 100점 |
16. 수강생 주의사항
- 첫 주에 기능 구현부터 시작하지 말고 서비스 시나리오와 요구사항을 먼저 확정해야 합니다.
- TurtleBot3 패키지 이름을 그대로 사용하지 말고 팀 이름이 포함되도록 재구성해야 합니다.
- 다른 팀의 지도나 파라미터를 복사해서 제출하면 안 됩니다.
- 측정하지 않은 수치를 예상값으로 작성하면 안 됩니다.
- 한 번 성공한 결과를 최종 결과로 판단하면 안 됩니다.
- 최소 10회 이상 반복하여 성공률과 오차를 확인해야 합니다.
- 센서를 장착만 하고 서비스 동작에 사용하지 않으면 적용으로 보기 어렵습니다.
- 원격 PC가 꺼져도 핵심 서비스가 동작해야 합니다.
- Wi-Fi 연결 상태만을 전제로 시스템을 설계하면 안 됩니다.
- 비상 정지 수단을 가능하면 준비해야 합니다.
- 로봇 속도를 과도하게 높이면 정밀도와 안전성이 모두 떨어집니다.
- 마지막 주에는 기능 추가보다 오류 수정과 반복 시험에 집중해야 합니다.
- 매일 작업 종료 전에 GitHub에 소스를 반영해야 합니다.
- 특정 팀원 한 명의 컴퓨터에만 최신 소스가 존재하면 안 됩니다.
- 발표 당일 인터넷 연결이 없어도 실행 가능하도록 모든 파일을 로컬에 준비해야 합니다.
- YOLO 모델, 지도, 음성 파일, 설정 파일의 절대 경로 사용을 피해야 합니다.
- 실행 경로는 ROS 2 패키지의 Share Directory를 기준으로 처리해야 합니다.
- 센서와 카메라의 USB 장치 번호가 변경되는 상황을 고려(심볼릭 링크 사용)해야 합니다.
- 로봇별 ROS_DOMAIN_ID와 네임스페이스를 구분해야 합니다.
- 두 로봇을 동시에 운용할 때 서로 동작에 간섭이 발생하지 않도록 시나리오 작성시에 고려해야 합니다.
17. 프로젝트 완료 기준
다음 조건을 모두 만족해야 프로젝트가 완료된 것으로 판단합니다.
- 전원을 켜면 로봇 시스템이 자동으로 실행됩니다.
- 시작 위치가 초기화됩니다.
- 팀이 작성한 지도에서 Localization이 됩니다.
- 10개 이상의 경유점을 주행합니다.
- 2개 이상의 Trajectory를 수행합니다.
- 목표점 도착 오차가 3cm 이내입니다.
- 직진 이동 오차를 1cm 이하로 조정합니다.
- 좁은 통로를 통과합니다.
- 이동 장애물을 회피합니다.
- 다른 로봇과 교차 주행합니다.
- 후진 중 후방 장애물을 감지합니다.
- 센서 3개 이상이 서비스에 사용됩니다.
- 카메라 응용 기능이 동작합니다.
- ArUco 마커가 실제 서비스에 사용됩니다.
- 충전 스테이션 파킹이 동작합니다.
- 음성 또는 효과음 안내가 동작합니다.
- Wi-Fi가 끊겨도 정의된 안전 동작을 수행합니다.
- GUI에서 로봇 상태 확인과 임무 제어가 가능합니다.
- 전체 시나리오를 반복 실행할 수 있습니다.
- 요구사항 및 설계 문서가 GitHub에 등록되어 있습니다.
이번 프로젝트의 핵심은 많은 기능을 넣는 것이 아니라 실제 로봇에서 반복적으로 동작하는 완성도 높은 서비스를 만드는 것입니다. 요구사항을 먼저 정리하고, 기능을 작은 단위로 시험한 다음, 마지막에 하나의 상태 머신으로 통합해야 합니다.