하드웨어 디버깅 체크리스트

디버깅은 순서의 기술이다

로봇을 만들다 보면 언젠가는 이런 순간이 온다. 업로드도 잘 됐고, 배선도 분명히 맞게 한 것 같은데 로봇이 움직이지 않는다. 혹은 더 난감하게도, 움직이긴 하는데 내가 원한 방향이 아니다. 모터가 갑자기 튀고, 센서값은 춤을 추고, 보드는 주행 중간에 리셋된다.

이때 가장 위험한 생각은 '대충 여기쯤 문제겠지' 하고 여러 곳을 한꺼번에 고치는 것이다. 모터 배선을 바꾸고, 코드도 바꾸고, 배터리도 바꾸고, 센서 위치도 바꾸면 잠깐 해결된 것처럼 보일 수 있다. 하지만 진짜 원인을 모르면 다음 프로젝트에서 같은 문제가 다시 나타난다.

하드웨어 디버깅의 핵심은 멋진 장비가 아니라 순서다. 전원부터 보고, 신호를 보고, 부품을 하나씩 분리해서 확인한다. 로봇은 보드, 센서, 모터, 전원, 통신이 동시에 얽힌 장치이므로 문제를 한 번에 잡으려 하지 말고 작은 블록으로 나누어야 한다.

가장 좋은 질문은 이것이다.

'지금 내가 확실히 아는 것은 무엇이고, 아직 확인하지 않은 것은 무엇인가?'

이 장에서는 로봇 제작 중 자주 만나는 문제를 전원, 모터, 센서, 통신, 노이즈, 제어 동작으로 나누어 점검한다. 마지막 장답게, 앞에서 배운 모든 내용을 실제 작업대 위에서 써먹을 수 있는 체크리스트로 정리해 보자.

디버깅 전에 준비할 도구

로봇 디버깅을 시작하기 전에 준비물이 있으면 시간이 크게 줄어든다. 꼭 비싼 장비가 필요한 것은 아니다. 오히려 초보 단계에서는 멀티미터 하나와 차분한 기록 습관이 오실로스코프보다 더 큰 도움이 될 때가 많다.

다음 도구를 작업대 가까이에 두자.

• 멀티미터: 배터리 전압, 보드 입력 전압, GND 연결, 단선 여부를 확인한다.

• USB 케이블과 보조 전원: 보드만 따로 켜서 코드와 통신을 확인할 때 쓴다.

• 예비 점퍼선: 점퍼선 내부 단선이나 헐거운 접촉을 의심할 때 바로 교체한다.

• 작은 드라이버와 핀셋: 터미널 블록, 모터 드라이버, 센서 커넥터를 다시 조일 때 필요하다.

• 테스트 LED 또는 간단한 부하: GPIO 출력이 실제로 변하는지 확인할 수 있다.

• 노트 또는 로그 파일: 어떤 값을 바꾸었고 결과가 어땠는지 기록한다.

특히 멀티미터는 로봇 제작자의 손전등과 같다. 어두운 방에서 더듬거리며 물건을 찾지 말고, 전압을 직접 찍어 보자. '전원이 들어왔을 것이다'와 '5.02V가 측정된다'는 완전히 다르다.

첫 번째 원칙: 한 번에 하나만 바꾼다

디버깅할 때는 한 번에 하나의 조건만 바꿔야 한다. 배터리를 바꾸면서 코드도 수정하고 배선도 바꾸면, 문제가 해결되어도 무엇이 원인이었는지 알 수 없다.

예를 들어 모터가 돌지 않는다면 먼저 모터 전원 전압을 측정한다. 전압이 정상이라면 제어 핀을 확인한다. 그다음 드라이버 활성화 핀, 공통 GND, 모터 자체를 차례로 본다. 이 순서를 지키면 원인이 하나씩 좁혀진다.

좋은 디버깅은 추리와 비슷하다. 범인을 잡기 위해 모든 사람을 동시에 의심하는 것이 아니라, 알리바이를 하나씩 확인한다. 로봇도 마찬가지다. 전원은 정상인가? 신호는 나가는가? 드라이버는 받아들이는가? 모터는 살아 있는가? 이렇게 질문을 나누면 복잡해 보이던 문제가 갑자기 작아진다.

전원이 들어오지 않을 때

로봇이 아예 켜지지 않는다면 가장 먼저 전원을 봐야 한다. 코드나 센서부터 의심하고 싶겠지만, 전원이 없으면 어떤 코드도 실행되지 않는다.

전원 문제는 다음 순서로 확인한다.

• 배터리 또는 어댑터의 실제 전압이 충분한가?

• 플러스와 마이너스 극성이 뒤바뀌지 않았는가?

• 스위치, 커넥터, 터미널 블록이 제대로 연결되어 있는가?

• 보드의 VIN, 5V, 3.3V 핀 중 올바른 입력에 전원을 넣었는가?

• GND가 끊어져 있거나 엉뚱한 곳에 연결되어 있지 않은가?

배터리는 표시 전압만 믿으면 안 된다. 7.4V 리튬 배터리라고 적혀 있어도 방전되면 그보다 낮아진다. USB 보조배터리도 모터가 순간적으로 큰 전류를 요구하면 출력이 꺼질 수 있다. 그러므로 보드가 켜지지 않을 때는 배터리를 분리한 상태와 연결한 상태의 전압을 모두 측정해 보는 것이 좋다.

극성도 반드시 확인해야 한다. 플러스와 마이너스가 바뀌면 보드가 켜지지 않는 정도로 끝나지 않을 수 있다. 보호 회로가 없는 모듈은 바로 손상될 수 있다. 처음 전원을 넣기 전에는 손가락보다 멀티미터가 먼저 가야 한다.

작업대에서 자주 만나는 상황은 스위치나 터미널 블록 문제다. 겉보기에는 선이 꽂혀 있어도 나사가 느슨하면 전류가 제대로 흐르지 않는다. 로봇이 움직이다가 갑자기 꺼진다면 커넥터가 흔들리면서 접촉이 끊기는 경우도 많다. 이동 로봇은 진동이 생기므로, 가만히 있을 때 정상인 배선도 주행 중에는 문제가 될 수 있다.

보드가 자꾸 리셋될 때

전원이 들어오긴 하는데 모터가 돌 때마다 보드가 재시작된다면, 거의 대부분 전원 강하를 의심해야 한다. 전원 강하는 전압이 순간적으로 떨어지는 현상이다. 모터는 처음 출발할 때 큰 전류를 요구한다. 이때 배터리나 전압 변환기가 충분히 버티지 못하면 보드의 전압까지 떨어지고, 마이크로컨트롤러가 리셋된다.

증상은 꽤 뚜렷하다. USB로 보드만 연결하면 잘 동작한다. 센서값도 잘 나온다. 그런데 모터 전원을 연결하고 출발시키는 순간 시리얼 모니터가 끊기거나, 보드의 전원 LED가 깜빡이거나, 프로그램이 처음부터 다시 실행된다.

이때는 다음 순서로 확인한다.

• 모터 전원과 보드 전원을 분리했는가?

• 두 전원의 GND는 공통으로 연결했는가?

• 배터리의 전류 공급 능력이 모터의 요구 전류보다 충분한가?

• 전압 변환기의 정격 전류가 부족하지 않은가?

• 모터 출발 PWM을 너무 갑자기 크게 주고 있지 않은가?

보드와 모터를 같은 전원에서 바로 공급하면 문제가 생기기 쉽다. 특히 DC 모터 두 개가 동시에 출발하는 바퀴 로봇에서는 순간 전류가 크게 튄다. 가능하면 모터용 배터리 또는 전압 변환기와 보드용 전원을 분리하자. 단, 신호 기준을 맞추기 위해 GND는 반드시 연결해야 한다. 여기서 중요한 표현은 '전원은 분리, GND는 공유'다.

전원 강하를 줄이는 실용적인 방법도 있다. 모터에 PWM을 바로 255로 주지 말고 0에서 천천히 올리는 소프트 스타트를 적용한다. 배터리 근처와 모터 드라이버 전원 입력 근처에 적절한 커패시터를 추가하면 순간적인 흔들림을 줄이는 데 도움이 된다. 커패시터는 작은 물탱크처럼 순간적으로 필요한 전하를 보충해 주는 부품이라고 생각하면 된다.

모터가 움직이지 않을 때

모터가 움직이지 않는 문제는 원인이 많아 보이지만, 실제로는 네 구간으로 나눌 수 있다. 제어 보드가 신호를 내보내는가, 모터 드라이버가 그 신호를 받는가, 드라이버에 모터 전원이 들어오는가, 모터 자체가 정상인가. 이 네 질문을 순서대로 확인하면 된다.

먼저 모터 자체부터 분리해서 확인한다. 모터를 드라이버에서 빼고, 모터 정격에 맞는 낮은 전압 전원에 아주 짧게 연결해 본다. 이때 손으로 축을 잡아 억지로 멈추게 하면 안 된다. 모터가 정상이라면 짧게라도 회전한다. 모터 자체가 돌지 않는다면 코드와 드라이버를 아무리 고쳐도 해결되지 않는다.

그다음 모터 드라이버 전원을 본다. 많은 초보자가 제어 보드의 5V만 연결하고 모터 전원 단자를 비워 둔다. 모터 드라이버에는 보통 두 종류의 전원이 필요하다. 하나는 로직 전원, 즉 제어 회로가 동작하기 위한 전원이다. 다른 하나는 모터에 실제로 공급되는 전원이다. 모터 전원 단자에 배터리가 연결되어 있지 않으면 드라이버는 명령을 받아도 모터를 돌릴 힘이 없다.

드라이버의 활성화 핀도 자주 놓친다. L298N 계열에서는 ENA, ENB 같은 핀이 있고, TB6612 계열에서는 STBY 핀이 있다. 이 핀이 비활성 상태이면 방향 핀을 아무리 바꾸어도 모터는 돌지 않는다. PWM을 넣는 핀과 방향을 정하는 핀을 코드에서 제대로 설정했는지도 확인해야 한다.

모터가 움직이지 않을 때의 기본 점검 순서는 다음과 같다.

• 모터 단독 테스트: 모터 자체가 회전하는지 확인한다.

• 모터 전원 확인: 드라이버의 모터 전원 단자에 실제 전압이 들어오는지 측정한다.

• 로직 전원 확인: 드라이버 제어 회로에 필요한 5V 또는 3.3V가 연결되어 있는지 본다.

• 공통 GND 확인: 보드 GND와 드라이버 GND, 모터 전원 GND가 연결되어 있는지 확인한다.

• 제어 핀 확인: 방향 핀, PWM 핀, 활성화 핀이 코드와 배선에서 일치하는지 본다.

• 드라이버 발열 확인: 손상되었거나 과부하 상태이면 드라이버가 비정상적으로 뜨거워질 수 있다.

모터가 한쪽만 돈다면 좌우를 바꾸어 보는 것도 좋은 방법이다. 왼쪽 모터를 오른쪽 드라이버 출력에 연결했을 때 문제가 따라가면 모터나 배선 문제일 가능성이 크다. 문제가 같은 드라이버 채널에 남아 있으면 드라이버나 제어 핀 문제일 가능성이 크다. 이렇게 부품을 교차 연결하면 원인을 빠르게 분리할 수 있다.

모터 방향이 반대로 돌 때

모터가 아예 안 도는 것보다 더 흔한 일이 있다. 앞으로 가라고 했는데 뒤로 가고, 왼쪽으로 돌라고 했는데 오른쪽으로 도는 경우다. 이것은 대부분 고장이 아니라 방향 정의가 맞지 않는 문제다.

DC 모터는 두 선의 극성을 바꾸면 회전 방향이 바뀐다. 따라서 한쪽 바퀴가 반대로 돈다면 그 모터의 두 선을 바꾸거나 코드에서 방향 핀 논리를 반대로 하면 된다. 어느 방법을 선택하든 프로젝트 안에서는 규칙을 정해야 한다. 예를 들어 forwardLeft와 forwardRight라는 함수가 실제로 로봇 기준 전진을 의미하도록 맞춰 두면 이후 제어 코드가 훨씬 깔끔해진다.

엔코더가 붙은 로봇에서는 방향 문제가 한 단계 더 복잡해진다. 모터는 앞으로 도는데 엔코더 카운트가 음수로 증가할 수 있다. 이 상태에서 속도 제어나 위치 제어를 적용하면 제어기가 오차를 줄이기는커녕 더 키울 수 있다. 모터 방향, 엔코더 방향, 로봇 좌표계를 반드시 같은 기준으로 맞춰야 한다.

처음에는 바퀴를 바닥에 내려놓지 말고 공중에 띄운 상태로 테스트하자. 바퀴 로봇은 방향이 틀린 상태로 바닥에서 테스트하면 책상 아래로 돌진하거나 케이블을 잡아당길 수 있다. 공중 테스트에서 왼쪽 바퀴와 오른쪽 바퀴가 기대한 방향으로 도는지 확인한 뒤 바닥 주행으로 넘어가는 것이 안전하다.

센서값이 이상할 때

센서값이 이상하다는 말은 꽤 넓다. 값이 계속 0일 수도 있고, 최댓값에 붙어 있을 수도 있고, 가끔 말도 안 되는 값이 튈 수도 있다. 혹은 값은 변하지만 실제 거리나 색상, 기울기와 맞지 않을 수도 있다.

센서 문제도 순서대로 나누면 어렵지 않다. 먼저 배선과 전원을 확인하고, 그다음 통신 또는 출력 방식, 마지막으로 코드의 변환식을 확인한다.

센서 점검 순서는 다음과 같다.

• 전원 전압 확인: 센서가 5V용인지 3.3V용인지 확인한다.

• GND 확인: 센서 GND와 보드 GND가 연결되어 있는지 본다.

• 신호선 확인: 아날로그 출력, 디지털 출력, I2C, SPI, UART 중 어떤 방식인지 구분한다.

• 핀 번호 확인: 코드에서 읽는 핀과 실제 연결한 핀이 같은지 확인한다.

• 출력 범위 확인: 원시값을 먼저 출력해 센서가 반응하는지 본다.

• 변환식 확인: ADC 값, 거리 단위, 각도 단위로 바꾸는 계산이 맞는지 본다.

가장 중요한 습관은 가공된 값보다 원시값을 먼저 보는 것이다. 예를 들어 거리 센서에서 갑자기 300cm가 나온다고 해서 바로 거리 계산식을 고치지 말자. 먼저 센서가 실제로 어떤 펄스 폭, 아날로그 값, 디지털 값을 내고 있는지 확인해야 한다. 원시값이 정상적으로 변한다면 변환식 문제일 수 있고, 원시값 자체가 변하지 않으면 배선이나 센서 동작 문제일 가능성이 높다.

아날로그 센서는 ADC 범위를 확인해야 한다. 아두이노 우노에서는 보통 0부터 1023까지의 값을 읽지만, ESP32에서는 보드 설정과 해상도에 따라 범위가 다를 수 있다. 같은 센서를 연결해도 보드가 달라지면 읽히는 숫자가 달라질 수 있다. 따라서 코드에 적힌 임계값은 절대적인 진리가 아니라 현재 보드와 환경에 맞춰 조정해야 하는 값이다.

I2C 센서는 주소 확인이 중요하다. 같은 종류의 모듈이라도 주소 선택 핀 상태에 따라 주소가 달라질 수 있다. IMU나 OLED 디스플레이가 반응하지 않는다면 배선보다 먼저 주소를 스캔해 보는 것이 빠를 때가 많다. 또 I2C에서는 SDA와 SCL을 바꾸어 꽂는 실수가 흔하다. 모듈에 적힌 글자를 믿되, 보드의 핀맵도 함께 확인해야 한다.

거리 센서는 주변 환경의 영향을 많이 받는다. 초음파 센서는 부드러운 천이나 비스듬한 벽에서 반사가 약해질 수 있다. 적외선 센서는 주변 조명과 대상 물체의 색에 영향을 받는다. ToF 센서도 반사율이 낮은 물체에서는 값이 불안정할 수 있다. 센서값이 이상할 때는 센서만 탓하지 말고, 센서가 바라보는 세계가 측정하기 쉬운 환경인지도 생각해야 한다.

라인 센서는 높이와 조명이 중요하다. 바닥에서 너무 멀면 흰색과 검은색의 차이가 줄어든다. 너무 가까우면 센서가 바닥에 닿거나 작은 요철에 민감해진다. 라인트레이서가 갑자기 선을 잃는다면 코드보다 센서 높이, 각도, 주변 빛을 먼저 확인해 보자.

IMU는 고정이 생명이다. 보드 위에 헐겁게 얹은 IMU는 로봇의 기울기를 재는 것이 아니라 자기 자신이 흔들리는 값을 잰다. 진동이 심한 프레임에서는 센서를 단단히 고정하되, 모터 진동이 직접 전달되지 않도록 위치를 조정해야 한다. 드리프트는 완전히 사라지지 않으므로, 필터링과 보정 기준도 함께 생각해야 한다.

통신이 안 될 때

통신 문제는 겉으로 보기에 조용하다. 모터처럼 소리를 내지도 않고, LED처럼 확실히 켜지지도 않는다. 그래서 더 답답하다. 하지만 통신도 기본 확인 순서가 있다.

시리얼 통신에서는 먼저 보드와 PC가 같은 속도로 대화하는지 확인한다. 코드에서 115200bps로 시작했는데 시리얼 모니터가 9600bps로 열려 있으면 글자가 깨지거나 아무것도 보이지 않을 수 있다. TX와 RX도 확인해야 한다. 보드와 보드가 UART로 연결될 때는 한쪽의 TX가 다른 쪽의 RX로 가야 한다. 그리고 역시 GND는 공통이어야 한다.

시리얼 명령이 들어가지 않는다면 줄바꿈 설정도 확인하자. 코드가 한 줄 단위로 명령을 읽도록 되어 있는데, 시리얼 모니터에서 줄바꿈 없이 보내면 명령이 완료되지 않은 것으로 판단할 수 있다. 반대로 코드가 한 글자 명령을 기대하는데 불필요한 줄바꿈 문자가 붙어 오면 예상하지 못한 동작을 할 수 있다.

I2C에서는 주소, 풀업, 배선 길이를 확인한다. SDA와 SCL에는 풀업 저항이 필요하다. 대부분의 모듈에는 이미 풀업 저항이 들어 있지만, 여러 모듈을 많이 연결하면 전체 저항값이 너무 낮아질 수 있고, 선이 길면 신호가 둔해질 수 있다. 로봇 안에서 I2C 선을 길게 끌고 다니는 것은 좋은 선택이 아니다.

SPI에서는 칩 선택 핀을 확인해야 한다. SCK, MOSI, MISO가 맞더라도 CS 핀이 잘못되면 장치가 응답하지 않는다. 여러 SPI 장치를 쓸 때는 각 장치마다 CS를 따로 가져야 한다. 디스플레이와 센서를 함께 연결할 때 한 장치가 버스를 붙잡고 있으면 다른 장치가 이상하게 동작할 수도 있다.

Wi-Fi와 Bluetooth에서는 전원과 거리도 함께 봐야 한다. ESP32가 Wi-Fi를 켜는 순간 전류 소모가 증가할 수 있다. 평소에는 잘 켜지던 보드가 무선 연결을 시작할 때 리셋된다면 통신 코드보다 전원 여유를 먼저 의심해야 한다. 로봇이 움직이면서 안테나 주변이 금속 프레임이나 배터리에 가려지는지도 확인해 보자.

노이즈가 심할 때

로봇에서 노이즈는 단순히 '값이 조금 흔들리는 현상'이 아니다. 센서값이 튀면 제어 출력이 흔들리고, 제어 출력이 흔들리면 모터 전류가 출렁이며, 그 전류가 다시 센서와 보드에 영향을 준다. 작은 흔들림이 로봇 전체의 떨림으로 커질 수 있다.

노이즈의 대표 원인은 모터다. DC 모터는 내부에서 브러시가 접촉하면서 전기적 잡음을 만든다. 또한 모터가 출발하거나 방향을 바꿀 때 큰 전류 변화가 생긴다. 이 변화가 전원선을 타고 보드와 센서로 들어오면 센서값이 갑자기 튀거나 보드가 리셋될 수 있다.

노이즈를 줄이기 위해 먼저 전원 구조를 정리한다. 모터 전원과 보드 전원을 분리하고, GND는 한 지점에서 만나도록 구성하면 전류가 센서 GND를 지나가며 흔들리는 일을 줄일 수 있다. 이것을 엄밀한 전자공학 용어로는 접지 구조라고 부르지만, 실전에서는 '큰 전류가 흐르는 길과 작은 신호가 흐르는 길을 섞지 않는다'고 기억하면 된다.

커패시터도 도움이 된다. 모터 드라이버 전원 입력 근처에는 비교적 큰 전해 커패시터를 두고, 보드와 센서 전원 근처에는 작은 세라믹 커패시터를 두면 순간적인 전압 흔들림을 줄일 수 있다. 커패시터는 만능 치료제는 아니지만, 전원 배선이 길거나 모터가 갑자기 출발할 때 생기는 흔들림을 완화하는 데 효과적이다.

배선도 중요하다. 모터선과 센서선을 나란히 길게 묶어 두면 모터에서 생긴 잡음이 센서선으로 유도될 수 있다. 가능하면 모터 전원선은 짧고 굵게, 센서 신호선은 모터선에서 떨어뜨려 배치한다. 모터선 한 쌍을 서로 꼬아 주면 주변으로 퍼지는 노이즈를 줄이는 데 도움이 된다.

소프트웨어 필터링도 필요하다. 센서값 하나를 그대로 믿지 말고 최근 몇 개 값을 평균내거나, 갑자기 튄 값은 무시하거나, 변화량을 제한할 수 있다. 예를 들어 거리 센서가 평소 30cm 근처를 읽다가 갑자기 300cm를 한 번 출력했다면 바로 후진 명령을 내릴 필요는 없다. 몇 번 연속 같은 경향이 나타나는지 확인한 뒤 판단하면 로봇이 덜 예민하게 움직인다.

노이즈 대책은 다음 순서로 적용하면 좋다.

• 전원 분리: 모터 전원과 제어 보드 전원을 분리하고 GND만 공통으로 묶는다.

• 커패시터 추가: 배터리, 모터 드라이버, 보드 전원 입력 근처에 적절히 배치한다.

• 배선 정리: 모터선은 짧고 굵게, 센서선은 모터선과 떨어뜨려 둔다.

• 필터링 적용: 이동 평균, 저역 통과 필터, 이상값 제거를 사용한다.

• 제어 주기 고정: 센서 읽기와 출력 갱신 간격을 일정하게 유지한다.

• 출력 변화 제한: PWM이 한 번에 크게 바뀌지 않도록 램프 처리를 넣는다.

로봇이 튀거나 떨릴 때

로봇이 의도보다 심하게 흔들리거나 제자리에서 덜덜 떤다면 기계 문제와 제어 문제를 함께 봐야 한다. 코드만 고쳐서는 해결되지 않을 수 있고, 반대로 나사를 조이는 것만으로도 해결되지 않을 수 있다.

먼저 바퀴와 프레임을 확인한다. 바퀴가 축에 제대로 고정되어 있지 않으면 회전할 때 흔들린다. 모터 브래킷이 느슨하면 모터 자체가 움직인다. 프레임이 휘어 있으면 좌우 바퀴가 바닥에 닿는 정도가 달라지고, 같은 PWM을 줘도 한쪽만 더 강하게 밀 수 있다.

그다음 제어 파라미터를 본다. P 제어에서 Kp가 너무 크면 작은 오차에도 큰 보정을 하므로 로봇이 좌우로 심하게 흔들린다. PID 제어에서 D 항이 너무 크면 센서 노이즈에 민감해지고, I 항이 너무 크면 오차가 누적되어 뒤늦게 큰 출력이 튀어나올 수 있다. 제어값을 조정할 때는 먼저 낮은 값에서 시작해 조금씩 올려야 한다.

제어 주기가 들쭉날쭉해도 로봇이 불안정해진다. 어떤 순간에는 10ms마다 제어하고, 어떤 순간에는 200ms가 지나서야 제어하면 같은 Kp라도 실제 반응이 달라진다. 센서 읽기, 계산, 모터 출력 갱신이 일정한 간격으로 이루어지도록 만들면 제어가 훨씬 예측 가능해진다.

특히 카메라 기반 로봇은 영상 처리 시간이 길어질 수 있다. 프레임마다 처리 시간이 다르면 모터 명령이 불규칙하게 갱신된다. 이때는 명령 갱신 주기를 제한하거나, 일정 시간 새 명령이 없으면 정지하도록 안전 조건을 넣어야 한다. 로봇은 마지막 명령을 영원히 믿으면 안 된다.

의도와 다르게 움직일 때

로봇이 움직이긴 하지만 기대와 다르게 움직인다면, 고장보다 기준 불일치일 가능성이 높다. 앞, 뒤, 왼쪽, 오른쪽이라는 말은 사람에게는 자연스럽지만 코드와 배선에는 자동으로 전달되지 않는다.

가장 먼저 좌우 모터 이름을 확인한다. 코드에서 leftMotor라고 쓴 핀이 실제 왼쪽 모터에 연결되어 있는가? 로봇을 앞에서 보고 왼쪽인지, 뒤에서 보고 왼쪽인지도 헷갈릴 수 있다. 항상 로봇의 진행 방향을 기준으로 왼쪽과 오른쪽을 정의하자.

센서 방향도 중요하다. 거리 센서가 앞을 본다고 생각했는데 실제로는 약간 위를 보고 있으면 낮은 장애물을 놓칠 수 있다. IMU의 X축과 Y축이 코드에서 생각한 방향과 다르면 기울기 보정이 반대로 들어간다. 카메라 화면에서 물체가 왼쪽에 보인다고 해서 로봇이 항상 왼쪽으로 돌아야 하는 것도 아니다. 카메라가 뒤집혀 장착되어 있으면 판단도 뒤집힌다.

엔코더 기반 위치 제어에서는 바퀴 지름과 카운트당 거리 계산을 확인해야 한다. 바퀴 지름을 잘못 입력하면 로봇이 목표 거리보다 짧게 가거나 길게 간다. 감속 구간이 너무 짧으면 목표 위치 근처에서 미끄러져 지나친다. 바닥 재질이 바뀌면 같은 제어값으로도 결과가 달라질 수 있다.

의도와 다른 움직임을 잡을 때는 다음과 같이 작은 명령부터 테스트한다.

• 왼쪽 바퀴만 천천히 전진시키고 실제 방향을 확인한다.

• 오른쪽 바퀴만 천천히 전진시키고 실제 방향을 확인한다.

• 양쪽 바퀴를 같은 PWM으로 돌려 직진성을 확인한다.

• 낮은 속도로 10cm 이동 명령을 주고 실제 이동 거리를 잰다.

• 제자리 회전 명령을 주고 회전 방향과 각도를 확인한다.

• 센서값 변화와 로봇 반응이 같은 방향인지 확인한다.

이 과정을 거치면 문제는 대부분 선명해진다. 왼쪽 모터가 반대로 연결되었는지, 엔코더 부호가 반대인지, 라인 센서의 좌우 인덱스가 뒤집혔는지, 카메라 좌표 판단이 반대인지 알 수 있다.

안전한 디버깅 절차

로봇은 움직이는 장치다. 따라서 디버깅 중에도 안전을 생각해야 한다. 작은 미니카 정도라도 갑자기 출발하면 USB 케이블을 잡아당기거나 책상 아래로 떨어질 수 있다. 로봇팔이나 큰 모터를 쓰는 장치라면 더 조심해야 한다.

처음 테스트할 때는 바퀴를 바닥에서 띄워 둔다. 상자나 블록 위에 로봇을 올려 바퀴가 공중에서 돌게 하면 예상치 못한 돌진을 막을 수 있다. 모터 방향과 PWM 범위를 확인한 뒤에야 바닥 주행을 시작하자.

코드에는 항상 안전한 기본 상태를 넣는 것이 좋다. 통신 명령이 끊기면 정지한다. 센서값이 말이 안 되는 범위로 나오면 정지한다. 배터리 전압이 너무 낮으면 무리하게 주행하지 않는다. 전원을 켰을 때 모터 핀이 초기화되기 전까지 드라이버가 켜지지 않도록 활성화 핀을 관리한다.

디버깅 중에는 손으로 바퀴를 잡아 멈추는 행동을 피해야 한다. 모터가 멈춘 상태에서 전류가 많이 흐르면 드라이버가 뜨거워지거나 모터가 손상될 수 있다. 이상 동작을 멈추려면 손보다 스위치가 먼저다. 가능하면 로봇 전원 스위치를 손이 닿기 쉬운 곳에 배치하자.

전체 점검표

문제가 생겼을 때 바로 사용할 수 있도록 전체 점검표를 정리해 보자. 모든 항목을 매번 다 볼 필요는 없지만, 원인을 모를 때는 위에서 아래로 차근차근 내려가면 된다.

이 표에서 가장 자주 반복되는 단어가 있다. 전원, GND, 배선, 핀 번호다. 로봇 문제의 상당수는 복잡한 알고리즘이 아니라 이 네 가지에서 시작된다. 반대로 말하면, 이 네 가지를 습관적으로 확인하는 사람은 디버깅 속도가 훨씬 빨라진다.

좋은 테스트 코드의 조건

큰 프로젝트 코드로 바로 디버깅하면 원인을 찾기 어렵다. 센서 읽기, 통신, PID 제어, 모터 출력이 모두 들어간 상태에서는 어느 부분이 문제인지 분리하기 힘들다. 그래서 작은 테스트 코드가 필요하다.

좋은 테스트 코드는 한 가지 일만 해야 한다. 모터 테스트 코드는 모터만 돌리고, 센서 테스트 코드는 센서값만 출력한다. 통신 테스트 코드는 받은 명령을 그대로 되돌려 보내는 정도면 충분하다. 이런 작은 코드를 준비해 두면 새 부품을 연결할 때마다 빠르게 확인할 수 있다.

프로젝트 폴더에 다음과 같은 테스트 파일을 따로 두면 좋다.

• test_motor_left: 왼쪽 모터의 방향과 PWM 범위를 확인한다.

• test_motor_right: 오른쪽 모터의 방향과 PWM 범위를 확인한다.

• test_encoder: 엔코더 카운트와 방향을 확인한다.

• test_distance_sensor: 거리 센서 원시값과 변환값을 출력한다.

• test_i2c_scan: I2C 장치 주소를 확인한다.

• test_serial_command: 명령 송수신과 줄바꿈 처리를 확인한다.

이런 테스트 코드는 한 번 만들고 끝나는 것이 아니다. 로봇을 분해했다가 다시 조립했을 때, 배터리를 바꿨을 때, 센서를 교체했을 때 계속 사용한다. 프로젝트가 커질수록 작은 테스트 코드의 가치는 커진다.

디버깅 로그를 남기는 습관

하드웨어 문제는 기억에 의존하면 같은 실수를 반복하기 쉽다. 어제는 잘 됐는데 오늘은 안 되는 것처럼 느껴지지만, 실제로는 배선을 하나 바꾸었거나 배터리 상태가 달라졌거나 코드를 조금 수정했을 수 있다. 그래서 디버깅 로그가 필요하다.

로그는 거창할 필요가 없다. 날짜, 증상, 확인한 항목, 측정값, 바꾼 내용, 결과만 적으면 된다. 예를 들어 '모터 출발 시 보드 리셋, 배터리 7.6V, 모터 출발 순간 5V 레일이 3.9V까지 하락, 보드 전원 분리 후 해결' 정도면 충분하다. 이런 기록은 다음 로봇을 만들 때 훌륭한 참고서가 된다.

사진도 큰 도움이 된다. 배선 사진을 위에서 한 장, 옆에서 한 장 찍어 두면 나중에 문제를 되짚기 쉽다. 특히 브레드보드나 점퍼선이 많은 프로젝트에서는 사진 한 장이 긴 설명보다 정확하다. 문제가 해결된 배선은 반드시 기록해 두자. 해결된 상태를 저장하지 않으면, 다음 수정에서 다시 길을 잃을 수 있다.

로봇을 완성하는 사람의 태도

로봇 제작에서 디버깅은 실패의 흔적이 아니라 완성으로 가는 과정이다. 한 번에 완벽하게 움직이는 로봇은 거의 없다. 실제 로봇은 배터리가 약해지고, 바닥이 바뀌고, 센서가 흔들리고, 모터가 뜨거워진다. 책상 위에서 잘 되던 코드가 바닥 위에서는 다르게 보일 수 있다.

중요한 것은 문제를 만났을 때 겁먹지 않는 것이다. 전원부터 확인한다. GND를 본다. 신호를 나눈다. 부품을 하나씩 테스트한다. 원시값을 출력한다. 제어값을 낮춘다. 한 번에 하나만 바꾼다. 이 단순한 습관들이 쌓이면, 처음에는 정체불명의 고장처럼 보이던 문제도 결국 설명 가능한 현상이 된다.

이 책에서 우리는 로봇 하드웨어의 구성부터 전원, 모터, 센서, 통신, 제어, 그리고 여러 미니 프로젝트까지 차례로 살펴보았다. 이제 마지막으로 기억해야 할 것은 이것이다. 로봇은 부품을 연결했다고 완성되는 것이 아니라, 문제를 발견하고 고쳐 가는 과정 속에서 완성된다.

다음번 로봇이 이상하게 움직이면 당황하지 말자. 멀티미터를 들고, 체크리스트를 펼치고, 첫 질문으로 돌아가면 된다.

'전원은 정말 정상인가?'

대부분의 멋진 로봇은 바로 그 질문에서 다시 살아난다.