증상
오늘은 삽질 기록이다.
ros2 launch를 실행했는데 AMCL이 map → odom TF를 퍼블리시하지 않는 상황이 발생했다.
에러 로그도 없었다. AMCL 노드는 멀쩡히 떠 있었다. 근데 TF는 없었다.
rviz를 열어보면, /map topic에 아무것도 안 뜬다.
map → odom이 끊겨 있으니 당연히 로봇 위치도 안 잡히고, Nav2도 뻗는다. 아무 에러도 없는데 아무것도 안 된다. 제일 무서운 패턴이다...
비슷한 증상이 하나 더 있었다. Ctrl+C를 연타해서 bringup을 끄고 바로 다시 켜면, 이번엔 LiDAR 자체를 인식하지 못하는 에러가 뜨는 것이었다. 처음엔 별개의 문제라고 생각했는데, 알고 보니 같은 원인이었다.
의심한 것들
처음엔 당연히 AMCL 설정을 의심했다.
- 노드 실행 순서 문제인가?
- QoS 미스매치로 토픽을 못 받고 있나?
다 확인해봤다. 다 정상이었다.
그다음엔 scan 토픽을 의심했다. AMCL은 /scan 토픽을 받아야 동작하는데, 혹시 LiDAR 데이터가 제대로 안 들어오는 건 아닐까?
ros2 topic echo /scan데이터는 잘 들어오고 있었다. 의심할 곳이 없어지기 시작했다.
범인 특정
막혀서 기본으로 돌아갔다. 현재 떠 있는 노드 목록부터 다시 확인해보자.
ros2 node list그런데 출력이 이상했다.
/sllidar_node
/sllidar_node
/amcl
/map_server
.../sllidar_node가 두 개였다.
sllidar_node는 Pinky Pro 로봇에 붙어 있는 LiDAR 패키지의 노드다. bringup을 실행하면 이 노드가 함께 올라오는데, 이전 세션에서 Ctrl+C로 종료했을 때 프로세스가 완전히 죽지 않고 살아남은 것이었다. 겉으로 보기엔 ros2 node list에서 중복으로 뜨는 것 말고는 아무 이상이 없었다.
문제는 이 좀비 노드가 /scan 토픽을 물고 있었다는 것이다. AMCL은 /scan을 정상적으로 구독하고 있었지만, 좀비 sllidar_node와 충돌하면서 데이터를 제대로 처리하지 못했고, 결과적으로 map → odom TF를 퍼블리시하지 못한 것이었다.
구조로 정리하면 이렇다.
두 노드가 같은 토픽에 퍼블리시하면서 AMCL이 혼선을 일으킨 것이다.
해결
1. 좀비 프로세스 죽이기
일단 좀비 프로세스를 죽이는 게 먼저였다.
# 프로세스 PID 확인
ps aux | grep sllidar
# 킬
kill -9 <PID>이후 다시 launch를 실행하니 map → odom TF가 정상적으로 퍼블리시됐다.
2. 재발 방지: systemd 파일
재발 방지가 문제였다. bringup 파일은 팀 전체가 공유하는 파일이라 직접 수정하기가 어려운 상황이었다. launch 파일 내부에 종료 핸들러를 달거나 노드 구성을 바꾸는 건 협업 흐름상 맞지 않았다.
그래서 Raspberry Pi에 별도의 systemd 서비스 파일을 만들어서, bringup을 서비스 단에서 관리하도록 했다. systemctl stop으로 끄면 관련 프로세스가 확실히 정리되고, systemctl start로 다시 켜는 방식이다.
ExecStopPost에 pkill -f sllidar_node를 넣어뒀기 때문에, 서비스가 종료될 때 좀비 프로세스가 남지 않는다. Ctrl+C 연타로 인한 라이다 인식 실패 문제도 이걸로 같이 잡혔다.
회고
이번 삽질에서 배운 것 하나만 꼽으라면, 에러 로그 없는 버그가 제일 무섭다는 것이다.
에러가 있으면 거기서부터 따라가면 된다. 근데 노드도 살아있고, 토픽도 들어오고, 로그도 없는데 TF만 없는 상황은 어디서부터 파야 할지 감이 안 잡힌다.
앞으로 ROS2 디버깅 순서를 이렇게 잡기로 했다.
ros2 node list— 노드 중복 여부 먼저 확인ros2 topic list/ros2 topic echo— 토픽 정상 여부 확인ros2 topic info <topic>— 퍼블리셔/서브스크라이버 수 이상 여부 확인- 그다음 설정 파일 확인
설정보다 환경 먼저 의심하는 습관을 들이는 게 맞는 것 같다.
