Side Project/ROS2 & LLM Autonomous Robot

MentorPi 개발 환경 구성하기

ns4A 2026. 1. 29. 08:54

— 원격 접속, 네트워크, 라즈베리파이/확장보드, Docker까지 한 번에 정리해봅니다

 

로봇 개발은 “코드만 잘 짜면 되는 문제”처럼 보이지만, 실제로는 환경이 절반 이상을 차지하는 경우가 많습니다.
특히 ROS 2처럼 의존성이 많은 생태계에서는 다음 상황을 정말 자주 마주치게 됩니다.

  • 같은 코드를 돌렸는데 결과가 다르다
  • 하루 전에 되던 게 오늘은 안 된다
  • 버전 충돌(OpenCV/PCL/ROS2/Gazebo)로 설치가 꼬인다

그래서 이 글에서는 MentorPi를 재현 가능한 개발 환경으로 만드는 과정을 정리합니다.
이걸 해두면, 나중에 SLAM/Navigation/비전 파트에서 문제가 생겨도 “환경 문제인지, 코드 문제인지”를 분리해서 추적하기 쉬워질 것 같습니다.


1. VNC Viewer

VNC(Viewer)는 원격지 컴퓨터의 화면을 네트워크로 받아서, 내 PC에서 마치 직접 쓰는 것처럼 조작하게 해주는 도구입니다.
키보드/마우스 입력을 원격으로 보내고, 화면을 실시간으로 받아오는 방식입니다.

  • VNC는 내부적으로 RFB(Remote Frame Buffer) 프로토콜을 사용합니다.
  • Windows/macOS/Linux에서 모두 사용할 수 있습니다.
  • 원격 협업, 원격 유지보수, 교육용 환경에서 많이 쓰입니다.

📌 왜 로봇에서 유용할까요?
로봇 내부의 라즈베리파이에 모니터/키보드를 매번 꽂지 않고도, GUI 설정/파일 탐색/터미널 작업을 안정적으로 수행할 수 있기 때문입니다.

1-2. VNC 종류가 여러 개인데, 무엇을 쓰는 게 좋을까?

VNC 계열은 대표적으로 RealVNC, TightVNC, UltraVNC, TigerVNC 등이 있습니다.
각자의 장단점이 있는데, 보통 로봇 개발에서는 “설치가 쉽고, 기본 보안이 있는지”가 중요하게 작용합니다.

 

라이선스 상용(무료 제한) 오픈소스 오픈소스 오픈소스
지원 OS Win/macOS/Linux/모바일 Win/Linux 주로 Win Win/Linux/macOS
특징 기능/보안 기본 탑재 가볍고 단순 부가기능(파일전송 등) 성능/현대적 지원
보안 TLS 기본 제공 기본 암호화 약함 플러그인 의존 TLS 지원

여기서는 “삽질을 줄이는” 쪽이 더 중요해 보여서 RealVNC Viewer를 사용합니다.


 

2. 로봇 네트워크 환경: AP 모드와 STA 모드

MentorPi 네트워크는 크게 두 가지 모드로 동작합니다.

  • AP(Access Point) 모드
    로봇이 핫스팟을 직접 만들어서, PC/스마트폰이 로봇에 “직접 연결”하는 방식입니다.
    다만 외부 인터넷은 보통 사용할 수 없습니다.
  • STA(Station) 모드
    로봇이 집/회사 공유기 같은 기존 Wi-Fi 네트워크에 접속하는 방식입니다.
    인터넷 접근이 가능하고, 개발 흐름이 자연스럽습니다.

기본은 AP 모드로 시작하는 경우가 많고, 실제 개발은 STA 모드가 더 편한 경우가 많습니다.


2-1. AP 모드로 접속하기 (빠른 첫 연결)

AP 모드에서는 보통 아래 흐름으로 갑니다.

  1. 로봇 전원 ON → HW-xxxx 같은 SSID가 뜸
  2. 비밀번호 hiwonder로 연결
  3. VNC Viewer에서 기본 IP 192.168.149.1로 접속
  4. 계정 pi, 비밀번호는 기본 설정 값으로 로그인

📌 주의할 점
PC를 AP에 붙이면, PC가 원래 연결하던 인터넷망에서 떨어질 수 있습니다.
영상 시청/문서 열람이 동시에 필요하면, 스마트폰으로 설정하는 편이 더 편할 수 있습니다.


2-2. STA 모드로 전환하기 (개발용 권장 흐름)

STA 모드는 “로봇이 공유기에 붙는 구조”라서, 이후 작업이 훨씬 편해집니다.

  • 패키지 설치/업데이트
  • 원격 저장소 연동
  • 여러 기기(PC/폰/다른 로봇)와의 연동

스마트폰 앱(WonderPi)로 설정하는 방식이 가장 간단하고,
직접 설정 파일을 수정하는 방식도 가능합니다.



2-3. 설정 파일 기반 전환과 “우선순위” 이슈

앱으로 설정하면 /etc/wifi/wifi_conf.py가 생성될 수 있고,
이 파일이 존재하면 우선순위가 더 높게 적용되는 구조였습니다.

 

네트워크가 안 바뀔 때는 “명령을 다시 쳐봤는데도 안 된다”로 끝내기보다,
어느 설정 파일이 최종 적용되는지부터 추적하는 게 빠릅니다.


2-4. IP가 매번 바뀌는 문제: DHCP 예약이 사실상 필수에 가깝습니다

STA 모드에서 로봇 IP가 재부팅마다 바뀌면,
VNC/SSH 접속 주소가 흔들리면서 개발 흐름이 끊깁니다.

이때 공유기에서 MAC 주소 기반 DHCP 예약(IP 바인딩)을 잡아두면 훨씬 안정적입니다.

  • ifconfig로 MAC 주소 확인
  • 공유기 설정에서 해당 MAC에 고정 IP 할당
  • 재부팅/서비스 재시작 후 동일 IP 유지 확인


3. 라즈베리파이 5와 확장 보드: MentorPi 하드웨어 구조 이해

3-1. Raspberry Pi 5는 어떤 의미가 있을까?

Raspberry Pi 5는 SBC(Single Board Computer)이고, MentorPi의 “호스트 컴퓨터” 역할을 합니다.
즉, 로봇 안에서 ROS 노드, 네비게이션, 비전 같은 고수준 작업을 담당합니다.

주요 사양을 정리하면 아래와 같습니다.

항목사양
CPU Broadcom BCM2712 (Cortex-A76, 2.4GHz, 4-core)
GPU VideoCore VII (OpenGL ES 3.1, Vulkan 1.2)
RAM 4GB / 8GB
저장장치 microSD 또는 NVMe(PCIe 2.0 x1)
네트워크 GbE, Wi-Fi 5, Bluetooth 5.0
전원 USB-C (5V 5A 권장)

여기서 개인적으로 중요한 포인트는 PCIe 지원(NVMe 가능)과 전원 요구(5V 5A) 같은 “운영 안정성” 요소였습니다.
로봇은 장시간 구동하는 경우가 많아서, 이런 부분이 결국 시스템 안정성과 연결될 가능성이 큽니다.


3-2. 확장 보드(HiWonder RRC Lite)는 왜 필요한가?

라즈베리파이만으로도 많은 걸 할 수 있지만, 모터/서보처럼 실시간 제어가 필요한 영역은 MCU가 훨씬 유리합니다.
MentorPi는 STM32F407 기반 컨트롤러(RRC Lite)를 사용해서 이 역할을 분리해둔 구조입니다.

  • 모터/엔코더 4채널
  • PWM/Serial Servo 포트
  • IMU 센서
  • 과전류/과열/단락 보호 회로
  • PD fast-charging(전원 안정화)

특히 FPU(부동소수점 연산 하드웨어)가 있는 MCU를 쓰면,
자세제어/센서필터 같은 계산에서 소프트웨어 연산보다 안정적일 수 있습니다. (실제로 이 차이가 체감되는 경우가 꽤 있습니다.)



4. 데스크톱 환경과 “로봇 버전 변경” 포인트

VNC로 접속하면 라즈베리파이 데스크톱 환경을 그대로 볼 수 있고,
여기서 중요한 건 “단순 접속”이 아니라 설정 도구를 통해 로봇 구성을 바꿀 수 있다는 점입니다.

예를 들어:

  • Camera Type: ascamera(3D Depth) / usb_cam(2D)
  • Machine Type: MentorPi_Mecanum(M1) / MentorPi_Acker(A1)

A1(Ackermann)을 쓰는 입장에서는 여기서 Machine Type을 정확히 Acker로 맞추는 것이 첫 번째 체크포인트가 됩니다.


5. 서보 편차 조정: “로봇이 살짝 틀어지는” 문제를 다루는 방식

A1(Ackermann)에서는 조향 서보가 핵심이고,
조립 공차 때문에 중립 위치에서도 바퀴가 살짝 틀어지는 현상이 있을 수 있습니다.

이럴 때 “코드가 이상한가?”부터 보기보다,
먼저 서보 오프셋을 물리적으로 보정하는 게 순서상 맞아 보입니다.

작업 흐름은 대략 아래처럼 정리됩니다.

  1. ROS 자동 시작 서비스를 중지
 
~/.stop_ros.sh
  1. 서보 오프셋 조정 스크립트 실행
 
./Servo.sh
  1. 슬라이더로 오프셋 조정 → Save Offsets로 저장
  2. 필요하면 섀시 제어 노드 실행해서 적용 확인
 

 


6. Docker: 로봇 개발에서 ‘환경’을 고정하는 방법

6-1. Docker를 한 문장으로 보면

Docker는 애플리케이션을 컨테이너라는 단위로 패키징/배포/실행하게 해주는 플랫폼입니다.
컨테이너는 “코드 + 런타임 + 라이브러리 + 설정”을 함께 묶어서, 환경 차이를 줄여줍니다.

개발에서 흔히 나오는 말이 있죠.

  • “내 컴퓨터에서는 되는데요?”
  • “버전이 안 맞는다는데요?”
  • “똑같이 재현이 안 되는데요?”

이걸 구조적으로 줄여주는 게 Docker라고 이해하면 편합니다.


6-2. Docker vs VM은 뭐가 다를까?

  • VM은 Guest OS까지 포함해서 무겁지만 격리가 강합니다.
  • Docker는 호스트 커널을 공유해서 가볍고 빠릅니다.

MentorPi에서는 “무거운 격리”가 아니라,
Host(OS 안정) + Container(ROS 환경) 분리로 재현성과 안전성을 확보하는 쪽이 핵심으로 보입니다.


6-3. Docker 핵심 개념 정리

  • Image: 실행 가능한 패키지 템플릿(읽기 전용)
  • Container: Image의 실행 인스턴스(프로세스/파일시스템 분리)
  • Dockerfile: 이미지를 만드는 레시피
  • Docker Hub: 이미지 저장소(공유/다운로드)

7. MentorPi에서 Docker를 쓰는 이유가 명확한 지점

이 구조는 꽤 “로봇답다”고 느꼈습니다.

  • Host(Raspberry Pi OS)
    • GPIO, 하드웨어 접근
    • 시스템 안정성 유지
  • Container(Ubuntu 22.04 + ROS 2 Humble)
    • ROS 2 공식 지원 환경
    • 의존성 격리
    • 실험적 설치/실습이 Host를 오염시키지 않음

즉, “OS는 로봇을 안정적으로 돌리는 기반”,
“컨테이너는 개발/실험을 담는 공간”으로 분리한 느낌입니다.


8. Docker 실습 커맨드 정리

8-1. 컨테이너 확인

 
docker ps -a

출력에서 주로 확인하는 항목은 다음입니다.

  • CONTAINER ID: 컨테이너 식별자
  • IMAGE: 어떤 이미지 기반인지
  • STATUS: 실행 중인지/종료됐는지

8-2. 컨테이너 진입

 
docker exec -it -u ubuntu -w /home/ubuntu <container_id> /bin/bash

옵션의 의미는 다음과 같습니다.

  • -it: 인터랙티브 + tty
  • -u ubuntu: ubuntu 유저로 실행(권한 이슈 줄이기)
  • -w /home/ubuntu: 시작 작업 디렉토리 지정
  • /bin/bash: bash로 접속

8-3. 컨테이너 종료 vs detach

  • 완전히 종료:
 
exit
  • 종료하지 않고 빠져나오기(detach):
 
Ctrl + P + Q

detach는 “컨테이너는 계속 돌리고, 터미널만 빠지기”에 가깝습니다.
서비스를 끊지 않고 나오는 상황에서 유용합니다.


8-4. 마운트 경로 확인

 
docker inspect -f '{{range .Mounts}}{{println .Source "->" .Destination}}{{end}}' <Container ID or Name>

이건 Host↔Container 간 공유 디렉토리가 예상대로 붙었는지 확인할 때 꽤 도움이 됩니다.