hello, robot

Gazebo에서 Cartographer는 잘 돌아요. 라이다 스캔과 IMU를 받아 지도를 만들고, 키보드로 로봇을 몰면 지도가 채워져요. 그런데 같은 스택을 자작 기체에 올리면 SLAM 알고리즘에 닿기도 전에 다른 층이 먼저 무너져요.

스택Cartographer + Nav2 (시뮬에서 검증) 기체자작 · DC 모터 + 라즈베리파이 증상모터 기동 시 제어 보드 리셋 원인 층코드 아님 — 전원과 접지

증상은 리셋이었어요

세 가지가 함께 나타나요. 전원 전압이 평상시에도 출렁이고, 모터를 기동하는 순간 제어 보드가 리셋되고, 보호회로가 동작하면서 라즈베리파이까지 함께 내려가요.

코드를 의심하기 쉬운 자리인데 아니에요. 리셋은 프로그램이 죽는 것과 증상이 다르고, 무엇보다 모터를 돌릴 때만 일어나요. 특정 동작에서만 재현되는 실패는 그 동작이 건드리는 물리 층을 먼저 봐야 해요.

정지한 모터는 전기적으로 거의 단락이에요

DC 모터가 회전을 시작할 때는 정격보다 몇 배 큰 전류를 끌어요. 돌입 전류라고 불러요.

이유는 역기전력에 있어요. 모터가 돌면 코일이 회전 자기장 속을 지나며 전원과 반대 방향의 전압을 만들어내고, 그 역기전력이 전류를 제한해요. 그런데 정지 상태에서는 회전이 없으니 역기전력도 0이에요. 이때 전류를 막는 건 권선의 직류 저항뿐이라, 전기적으로는 거의 단락에 가까운 부하가 돼요.

리셋까지의 사슬
각 단계가 설계대로 동작한 결과예요.
모터 정지회전 0 → 역기전력 0전류 제한이 권선 저항뿐전기적으로 거의 단락돌입 전류정격의 몇 배배선·배터리 내부 저항에 전압 강하전원 레일 전체가 순간 내려앉음저전압 차단 동작SBC가 스스로 내려감 = 리셋보호회로가 고장난 게 아니에요공급 전압이 기준 아래로 떨어지면동작을 보장하지 않으니 스스로 내려가요.설계대로 일한 결과예요.그래서 보호회로를 끄는 건경고를 끄는 것이지 원인을 고치는 게 아니에요.모터를 돌릴 때만 재현되는 실패는그 동작이 건드리는 물리 층을 먼저 봐요.

접지를 공유하는 방식이 문제였어요

접지선을 하나로 묶어 로직과 모터가 같은 경로로 전류를 되돌리면 접지 전위 자체가 흔들려요. 접지선에도 저항과 인덕턴스가 있어서, 모터 전류가 그 선을 지날 때 전압 강하가 생기기 때문이에요. 기준이 되어야 할 0V가 모터 부하에 따라 출렁이면, 그 기준을 쓰는 로직 쪽 신호도 함께 출렁여요.

문제는 공유가 아니라 어디서 만나느냐예요
각 부하의 접지를 배터리 음극 한 점으로 따로 끌어와 그 지점에서만 만나게 해요.
한 가닥을 이어 쓰면배터리모터 드라이버로직 (SBC)한 가닥을 나눠 씀모터 전류가 만든 전압 강하가로직의 기준 0 V를 흔들어요스타 그라운드배터리모터 드라이버로직 (SBC)한 점에서만 만나요모터 전류가 로직 접지선을 안 지나가요접지를 아예 분리하면 안 돼요 — 시리얼 통신은 두 회로가 같은 기준 전압을 공유해야 성립해요. 문제는 공유가 아니라 어디서 만나느냐예요.

같이 쓰는 방법도 몇 가지 있어요.

조치원리
드라이버 전원 입력 가까이에 큰 커패시터돌입 전류를 국소적으로 공급해 배터리에서 끌어오는 순간 전류를 줄여요
모터 전류가 흐르는 선을 굵고 짧게저항이 줄어 전압 강하가 완화돼요
스타 그라운드모터 전류가 로직 접지선을 아예 안 지나가요

표준 기체가 한 번에 도는 이유

TurtleBot3에는 OpenCR이라는 제어 보드가 들어가요. MCU에 IMU가 올라가 있고 모터 구동과 전원 분배를 함께 맡으면서, 배터리 전압을 감시하고 모터 계통과 로직 계통을 보드 차원에서 나눠 둬요.

표준 기체가 “그냥 도는” 이유의 상당 부분이 알고리즘이 아니라 이 층에 있어요. 자작 기체는 그 층을 직접 만들어야 하고, 오늘 본 리셋이 그 대가예요. 튜토리얼이 매끄러운 것과 내 로봇이 도는 것 사이의 거리가 여기 있어요.

서보와 DC 모터는 다른 물건이에요

구동부에서도 같은 종류의 차이를 봤어요.

Feetech 서보DC 모터
엔코더·제어기한 몸에 내장없음 (따로 달아야)
명령목표 위치·속도전압(듀티)만
폐루프내부에서 돌아 값을 맞춤없음
상태 되읽기가능불가
같은 지령의 실제 속도일정배터리 전압·마찰·무게에 따라 달라짐

이 차이가 SLAM에 그대로 걸려요. 차동 구동 로봇의 오도메트리는 좌우 바퀴 회전량을 적분해 만드는데, 회전량을 못 재면 오도메트리가 성립하지 않아요. 엔코더가 있어도 개루프 DC 모터는 지령과 실제의 어긋남이 커서 누적 오차가 서보보다 빨리 쌓여요.

그래서 나온 판단이 흥미로웠어요. 조건이 좋은 구동부로 옮기는 대신 DC 모터로도 SLAM이 되게 만드는 쪽이 배울 게 많다는 거예요. 좋은 하드웨어에서는 드러나지 않는 문제가 여기서 다 나오고, 그걸 SLAM의 보정 능력으로 어디까지 덮을 수 있는지가 보이니까요.

진단에는 순서가 있어요

정리하면 실기체에서 무너진 세 층은 전원, 구동 정밀도, 센서 노이즈였어요. 셋 다 시뮬레이터에는 없거나 설정값으로만 존재하던 것들이에요.

1. 전원·배선      전압이 흔들리면 아래가 전부 재현 불가
2. 구동 정밀도    지령을 얼마나 따르는지
3. 센서·파라미터  노이즈와 신뢰 구간

전원이 흔들리는 상태에서 SLAM 파라미터를 아무리 만져도 결과가 재현되지 않아요. 재현되지 않는 실험은 데이터가 아니니까요.

마지막 층에도 원칙이 하나 있어요. 센서 사양과 SLAM 파라미터는 일치해야 해요. 라이다의 유효 거리가 8미터인데 알고리즘에는 더 멀리까지 유효하다고 적어두면, 센서가 재지 못하는 구간의 값을 관측으로 받아들여 지도에 없는 벽이 생겨요. 반대로 짧게 잡으면 멀리 있는 벽을 아예 못 보고 지도가 좁아지고요.

노이즈가 크다고 그 센서를 끄는 것도 답이 아니에요. IMU는 짧은 구간의 각속도가 정확하고 오래 보면 드리프트하는데, 바퀴 오도메트리는 그 반대예요. 어느 구간에서 무엇을 믿을지 정하는 게 파라미터 조정의 실체더라고요.

가상 시리얼로 검증한 코드가 실물에서 무너진 네 지점에서 시뮬레이터가 조용히 넘어가던 결함이 실물에서 드러나는 걸 봤는데, 이번엔 결이 조금 달라요. 그때는 소프트웨어의 가정이 틀린 것이었고 이번엔 아예 전기 쪽이에요. 점유 격자의 미지·자유 이분법이 만든 frontier 탐사 실패에서는 알고리즘이 보는 값과 실제 공간이 어긋나 있었고, 여기서는 그 값이 만들어지기 전 단계가 흔들리고 있었어요.

실기체로 넘어온다는 건 의심할 대상 목록이 위쪽으로 길어진다는 뜻이더라고요.