2.1 시뮬레이션 개요 · 인터랙티브 콘텐츠

2부부터는 TIKI-MINI를 직접 움직이는 코드를 짭니다. 2부에서는 로봇 앞에 앉기 전에 시뮬레이션 안에서 먼저 돌려 봅니다. 이 장은 시뮬레이션이 무엇이고 무엇을 보장하지 않는지부터 정리합니다.

시뮬레이션이란

로봇 코드는 토픽으로만 세상과 만납니다. 1.3장에서 본 대로 /cmd_vel에 속도를 발행하고 /odom, /scan을 구독하면 됩니다. 그 토픽의 반대편에 진짜 모터와 LiDAR 대신 소프트웨어가 앉아 있으면 그것이 시뮬레이션입니다. 코드는 상대가 로봇인지 시뮬레이터인지 모릅니다. 토픽 이름과 메시지 형식만 같으면 되기 때문입니다.

왜 시뮬레이션을 쓰는가

비용. 로봇은 한 대뿐이고 충전과 정비가 필요하며, 실습생이 여럿이면 순서를 기다려야 합니다. 시뮬레이션은 복사가 공짜입니다.
안전. 속도 제한을 잘못 잡았거나 회피 로직이 틀린 코드라면 책상 위 로봇보다 화면에서 처음 실행하는 편이 낫습니다. 로봇이 벽이나 사람, 책상 모서리에 부딪히는 일을 막습니다.
반복성. 같은 시작 위치와 같은 장애물 배치에서 코드를 열 번 돌려 결과를 비교합니다. 실제 바닥에서는 바퀴 상태와 시작 자세가 매번 조금씩 다릅니다.
정답을 안다. 시뮬레이터는 로봇의 진짜 위치를 알고 있어서 충돌 여부나 목표 도착을 바로 판정합니다. 실제 로봇은 자기 위치를 오도메트리로 추정할 뿐입니다.

시뮬레이션의 스펙트럼

시뮬레이션이라는 말은 폭이 넓습니다. 로봇 모델을 화면에 그리는 일부터 마찰과 관성까지 계산하는 일까지 모두 그렇게 부릅니다. 탭을 눌러 방식별로 무엇을 재현하고 얼마나 드는지 비교해 보세요.

예: 이 교재의 브라우저 에뮬레이터

속도 명령을 받아 수식으로 위치를 적분하고, 2차원 세계에서 거리를 계산해 /odom과 /scan을 만들어 냅니다. 힘과 질량은 계산하지 않습니다. 명령한 속도가 그대로 실현되는 이상적인 로봇입니다.

비용: 낮음. 브라우저만 있으면 되고 실행이 빠릅니다.
이 교재에서: 2.7, 2.8, 2.14장(브라우저): 코드 작성 연습

항목	운동학 에뮬레이션
URDF 모델과 TF 트리 표시	없음
/cmd_vel 입력에 따른 위치 변화	재현
/odom, /scan 같은 센서 토픽	재현
벽과의 충돌	재현
관성, 마찰, 바퀴 미끄러짐	없음
모터 응답, 통신 지연, 센서 잡음	없음

단순화는 비슷한 결과를 내지만 실제 물리와 같지는 않다는 뜻입니다. 위 표는 방식의 일반적인 성격이며 제품별 기능은 다를 수 있습니다.

세 방식은 서로를 대체하지 않습니다. 필요에 따라 고르는 도구입니다. 로직만 확인하려는데 물리 시뮬레이터를 띄우면 준비 비용만 큽니다. 반대로 바닥 마찰이 걱정인 문제를 운동학 에뮬레이터로는 답할 수 없습니다.

이 교재의 선택

환경	용도	이유
브라우저 에뮬레이터	2.6~2.8장, 2.14장의 코드 작성 연습	설치 없이 바로 돌고 코드와 결과가 한 화면에 있음
Ubuntu VM + RViz	3부의 VM 실습과 로봇을 연결했을 때 2.5장의 모델 확인	OVA에 있는 slam과 navigation 패키지를 확인하고, 로봇이 보내는 모델을 RViz로 볼 수 있음
실기기(TIKI-MINI)	4부	시뮬레이션에서 확인한 코드를 실제 로봇에 올림

브라우저 에뮬레이터는 /cmd_vel을 구독해 가상의 TIKI-MINI를 움직이고 /odom과 /scan을 발행합니다. 속도는 실제 컨트롤러 설정에 맞춰 직진 0.2 m/s, 회전 0.85 rad/s로 제한됩니다. 작은 2차원 세계(빈 공간, 복도, 장애물, 코스) 안에서 충돌과 목표 도착도 알려 줍니다. 구체적인 사용법은 2.6장 이후에 나옵니다.

세 환경에서 각각 무엇이 돌고 무엇을 주고받는지 나란히 놓았습니다. 실기기만 tiki 패키지 아래에 모터 보드와 LiDAR가 연결됩니다.

한계: 이 시뮬레이션이 알려 주지 않는 것

기본 구성의 에뮬레이터는 이상적입니다. 센서는 잡음이 없고, 로봇은 명령한 속도를 그대로 따르며, 시간은 가상으로 흐릅니다. /tf를 발행하는 노드나 robot_state_publisher도 없습니다. 실제 TIKI-MINI는 다릅니다. 코드를 읽어 보면 모터 제어 보드와 시리얼 통신(/dev/ttyAMA1, 921600 baud)으로 AT 명령을 주고받고, 엔코더는 한 바퀴에 1170틱입니다. 이 사이에 지연과 오차가 끼어듭니다.

질문	시뮬레이션 결과로 판단	비고
토픽 이름, 메시지 형식, 구독과 발행 구조가 맞는가	가능	코드 구조 검증
장애물을 보면 돌아가는 로직이 맞는가	가능	이상적 센서 기준
네 변을 돌았을 때 제자리로 오는가	일부만 가능	실제 바닥의 미끄러짐과 엔코더 오차는 없음
속도와 안전거리의 여유가 충분한가	불가	제동 거리, 지연, 센서 잡음에 달림
로봇이 실제로 장애물에 닿는가	불가	모델 크기와 센서 위치 오차
시작할 때 노드 순서와 타이밍 문제	불가	bringup 런치의 7초 타이머처럼 실제 구동에서만 드러남

시뮬레이션에서 되었으니 실제에서도 된다고 결론 내리지 마세요. 되었으니 실제에서 시도해 볼 만하다는 정도가 정확합니다. 4.6장에서 둘의 차이를 비교합니다.

도구 화면 미리 보기

시뮬레이션과 시각화에 쓰는 두 도구의 화면입니다. RViz2는 토픽을 구독해 로봇의 상태와 센서, 지도를 그려 주는 시각화 도구이고, 3.8장에서 직접 다룹니다.

Gazebo는 물리 엔진으로 로봇과 환경을 계산하는 시뮬레이터입니다. 충돌과 관성 같은 값을 실제로 계산해 주는 쪽이 이런 도구입니다.

2부 로드맵

장	주제	환경
2.2	커스텀 msg, srv 만들기 (준비 중)	브라우저
2.3	액션 서버와 클라이언트 작성 (준비 중)	브라우저
2.4	URDF와 TF, 로봇 모델	브라우저 도구, 마지막 절은 VM
2.5	tf2 변환 노드 작성 (준비 중)	브라우저
2.6	`/cmd_vel`과 차동구동	브라우저
2.7	직접 코딩 1: 정사각형 주행	브라우저
2.8	직접 코딩 2: 장애물 회피	브라우저
2.9	런치 파일과 `use_sim_time`	브라우저, 명령은 VM 또는 실기기
2.10	SLAM 설정 읽기	브라우저(설정 읽기)
2.11	지도 만들기(맵핑 실습)	브라우저(코드 실행)
2.12	Nav2 설정 읽기	브라우저(설정 읽기)
2.13	내비게이션 실습	브라우저(코드 실행)
2.14	미니 프로젝트	브라우저

TIKI-MINI 패키지 여섯 개의 구성은 VM이 필요해서 3부의 3.11장에서 다룹니다. OVA의 VM에는 그중 slam과 navigation 두 개가 있고 나머지는 로봇에서 실행합니다.

표의 환경은 계획이고, 각 장의 학습목표 상자가 최종 기준입니다.

한눈에 정리

시뮬레이션은 토픽의 반대편에 로봇 대신 소프트웨어를 두는 것이다. 코드는 바꾸지 않는다.
이유는 비용, 안전, 반복성, 그리고 정답 위치를 안다는 점이다.
방식은 시각화만, 운동학 에뮬레이션, 물리 시뮬레이터로 나뉘고 재현 범위와 준비 비용이 반대로 움직인다.
이 교재는 코딩 연습에 브라우저 에뮬레이터, 모델 확인에 VM과 RViz, 실제 구동에 TIKI-MINI를 쓴다.
에뮬레이터는 이상적이다. 센서 잡음, 미끄러짐, 지연, 타이밍 문제는 실기기에서만 드러난다.

확인 문제

Q1. 에뮬레이터에서 장애물 회피 코드가 100번 연속 성공했습니다. 실제 로봇에서도 성공한다고 말할 수 있나요?

말할 수 없습니다. 이상적인 센서와 명령 그대로의 속도를 가정한 결과입니다. 로직이 맞다는 근거는 되지만 안전거리나 제동 여유는 알려 주지 않습니다. 실기기에서 낮은 속도로 확인해야 합니다.

Q2. RViz로 로봇 모델을 띄우는 것과 운동학 에뮬레이터를 쓰는 것은 무엇이 가장 크게 다른가요?

RViz 시각화는 로봇을 그리기만 하고 /cmd_vel에 반응해 움직이지 않습니다. 운동학 에뮬레이터는 속도 명령을 적분해 위치를 바꾸고 /odom과 /scan을 만들어 냅니다.

다음 장

다음 장에서는 TIKI-MINI 패키지 6개의 구성을 읽고, OVA의 VM에 설치된 두 패키지를 확인합니다.