Navigation 멈춤 현상 오류 관련 해결 방안 문의

제품 별 문의 Humanoid G1
1

해당 bash 코드를 활용하여 navigation 기능을 활성화하고, unitree_g1_ros2_dev/nav2_patrol_v2.py at main · sangheonEN/unitree_g1_ros2_dev · GitHub

해당 코드를 활용해 목표 좌표로 이동하고 패트롤 하는 기능을 구현하여 동작시켰습니다.

그런데 10~20분 정도 지난 뒤에 첨부와 같이 오류가 발생하면서 rviz의 시각화가 멈추고, navigation 기능이 상실되는 문제가 발생했습니다.

오류 로그를 찾아보면 TF 변환 관련 실시간 처리가 원활히 되지 않아 발생하는 문제라고 나오더라구요.

혹시 이러한 오류가 발생하는 원인과 개선 방안이 있을지 문의를 좀 드립니다.

navigation_오류.zip (8.5 KB)

2

실제 로봇을 사용 중이라면 이 에러는 **“네트워크를 통한 두 컴퓨터 간의 시계 불일치”**일 확률이 95% 이상입니다.

로봇 내부의 컴퓨터(SBC)와 조종용 PC(Laptop)의 시간이 서로 다르면, 로봇이 보낸 데이터가 PC 입장에서는 “수백 초 전의 과거 데이터” 혹은 **“미래에서 온 데이터”**로 보이기 때문입니다.

:hammer_and_wrench: 해결 단계 (순서대로 따라해보세요)

1. 시간 동기화 (가장 확실한 해결책)

로봇과 PC 모두에서 아래 명령어를 실행하여 시간을 강제로 맞춥니다.

sudo apt update && sudo apt install ntpdate -y
sudo ntpdate ntp.ubuntu.com

Tip: 실전에서는 chrony 패키지를 설치하여 백그라운드에서 지속적으로 시간을 맞추는 것이 좋습니다.

2. use_sim_time 파라미터 체크

실제 로봇에서는 모든 노드의 use_sim_time이 **False**여야 합니다.

  • 만약 가제보(Gazebo)를 켜둔 상태로 실제 로봇을 연결했거나, 런치 파일에 use_sim_time:=True가 포함되어 있다면 False로 수정하세요.

3. TF 버퍼 사이즈 및 주기 확인

로봇의 센서 데이터나 주행 기록(Odom)이 나오는 속도에 비해 네트워크가 느리면 데이터가 밀릴 수 있습니다.

  • 명령어: ros2 run tf2_tools view_frames
  • 위 명령어로 생성된 frames.pdf를 열어보세요. 각 프레임 간의 **“Broadcaster”**와 **“Average Rate”**를 확인했을 때, 특정 구간의 레이턴시(Most recent transform)가 너무 크지 않은지 확인해야 합니다.

4. 고정 프레임(Fixed Frame) 설정

RViz 좌측 상단의 Global Options → Fixed Frame이 map 또는 odom으로 제대로 설정되어 있는지 확인하세요. 만약 존재하지 않는 프레임이 설정되어 있으면 메시지 드랍이 발생합니다.

:light_bulb: 요약하자면

현재 로그상으로는 로봇 시계와 PC 시계가 약 400초 정도 어긋나 있는 상태입니다.

  1. 로봇에서 date 입력
  2. PC에서 date 입력
  3. 두 시간의 초 단위까지 일치하는지 확인해 보세요.

혹시 로봇과 PC 사이의 통신은 와이파이(Wi-Fi)로 하고 계신가요? 네트워크 지연이 심할 경우에도 비슷한 증상이 나타날 수 있습니다.

3
  1. 혹시 로봇과 PC 사이의 통신은 와이파이(Wi-Fi)로 하고 계신가요?
  • 네 맞습니다. 현재 와이파이로 통신을 하고 있습니다.
  1. 가제보나 그런 것을 사용하지 않습니다. use_sim_time 파라미터 체크를 하라고 하셨는데, unitree_g1_ros2_dev/src/navigation2/nav2_bringup/params/nav2_params.yaml at main · sangheonEN/unitree_g1_ros2_dev · GitHub 이 제어 pc에서 사용되는 해당 경로에 있는 설정 말고는 제가 변경할 수 있는 설정 파일이 있을까요? 젯슨 내부에서 뭔가 설정을 해야되는 파일이 있는지요?
4

:puzzle_piece: 근본 원인

시간 동기화 불일치가 핵심 원인입니다. Wi-Fi 통신 환경에서 제어 PC와 Jetson(로봇) 사이의 시계(clock)가 동기화되어 있지 않거나, 특정 노드가 오래된 타임스탬프를 그대로 사용하고 있는 상황입니다.

구체적으로는 goal pose나 센서 데이터가 발행될 때 찍힌 타임스탬프가 현재 TF 버퍼에 없는 과거 시점을 참조하기 때문에 planner가 변환을 못 하고 멈추는 것입니다.

:white_check_mark: 해결 방법 (우선순위 순)

1. PC ↔ Jetson 시간 동기화 확인 (가장 중요)

두 기기 모두에서 아래 명령으로 시간을 확인하세요.

date
timedatectl

차이가 있다면 NTP 동기화를 강제 실행합니다.

sudo systemctl restart systemd-timesyncd
# 또는
sudo chronyc makestep

Wi-Fi 환경에서는 NTP 동기화가 불안정할 수 있으므로 chrony 사용을 권장합니다.

2. TF Buffer 크기 늘리기

nav2_params.yaml 또는 관련 launch 파일에서 TF 버퍼 유지 시간을 늘려줍니다.

bt_navigator:
  transform_tolerance: 1.0

# 또는 TF listener 초기화 시
tf_buffer_duration: 30.0  # 기본 10초 → 30초로 확장

3. transform_tolerance 파라미터 완화

nav2_params.yaml에서 아래 항목들을 찾아 값을 높여주세요.

controller_server:
  transform_tolerance: 1.0

planner_server:
  transform_tolerance: 1.0

bt_navigator:
  transform_tolerance: 1.0

4. DDS 유니캐스트 설정 (Wi-Fi 환경)

Wi-Fi에서 ROS2 멀티캐스트가 불안정하면 TF 데이터가 단속적으로 도달합니다. ~/.bashrc에 추가하세요.

export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp

그리고 CycloneDDS 유니캐스트 설정 파일을 적용하거나, 두 기기를 같은 서브넷에 두고 ROS_DOMAIN_ID를 맞춰주세요.

5. Goal Pose 발행 시 타임스탬프 확인

goal을 발행하는 코드나 RViz에서 stamp가 rclpy.time.Time()(현재 시간)으로 설정되어 있는지 확인하세요. 오래된 bag 파일이나 캐시된 goal이 재사용되고 있다면 383초 과거 타임스탬프 문제가 발생할 수 있습니다.

:pushpin: 요약

문제 원인 해결
Extrapolation Error (383초 차이) PC ↔ Jetson 시간 불일치 chrony로 NTP 동기화
Queue Full (odom2) Wi-Fi 지연/패킷 손실 DDS 유니캐스트, 토픽 Hz 조정
Navigation 멈춤 TF 변환 실패로 planner 중단 transform_tolerance 완화

가장 먼저 두 기기의 시간 차이를 확인하는 것이 우선입니다. 383초라는 차이는 단순한 지연이 아니라 시계 자체가 맞지 않는 수준이기 때문입니다.

5

1. PC ↔ Jetson 시간 동기화 확인 (가장 중요) 아래와 같이 ntp 동기화를 실행했습니다.

[제어 pc]
megagen@megagen-OMEN-MAX-Gaming-Laptop-16-ak0xxx:~/unitree_g1_lee$ date
2026. 02. 19. (목) 18:30:05 KST
megagen@megagen-OMEN-MAX-Gaming-Laptop-16-ak0xxx:~/unitree_g1_lee$ sudo systemctl restart systemd-timesyncd
[sudo] password for megagen: 
megagen@megagen-OMEN-MAX-Gaming-Laptop-16-ak0xxx:~/unitree_g1_lee$ date
2026. 02. 19. (목) 18:30:50 KST

[unitree g1 젯슨]
unitree@ubuntu:~$ date
Thu Feb 19 17:30:14 CST 2026
unitree@ubuntu:~$ sudo systemctl restart systemd-timesyncd
[sudo] password for unitree: 
unitree@ubuntu:~$ date
Thu Feb 19 17:30:43 CST 2026
  1. TF Buffer 크기 늘려고 했으나, tf_buffer_duration: 30.0 파라미터가 설정 파일에 보이지 않더라구요. 혹시 어디 설정 파일에 있는 값을 수정해야하나요?
  2. transform_tolerance 파라미터 완화. 아래 값들의 범위가 있을까요? min, max에 대한 범위를 문의드립니다. 또한 bt_navigator에 대한 transform_tolerance 설정 파라미터는 없는 것으로 보이는데 추가하면 되는 걸까요?

controller_server:
transform_tolerance: 1.0

planner_server:
transform_tolerance: 1.0

bt_navigator:
transform_tolerance: 1.0

  1. DDS 유니캐스트 설정 (Wi-Fi 환경) :

./g1_navigation.sh 파일에서 아래 source 명령이 수행되는데,

source ~/unitree_ros2/setup.sh 이 배시 파일은 아래와 같이 wifi interface wlo1과 RMW_IMPLEMENTATION=rmw_cyclonedds_cpp 이 설정이 포함되어 있습니다.

#!/bin/bash
echo "Setup unitree ros2 environment"
source /opt/ros/humble/setup.bash
source $HOME/unitree_ros2/cyclonedds_ws/install/setup.bash
export RMW_IMPLEMENTATION=rmw_cyclonedds_cpp
export CYCLONEDDS_URI='<CycloneDDS><Domain><General><Interfaces>
                            <NetworkInterface name="wlo1" priority="default" multicast="default" />
                        </Interfaces></General></Domain></CycloneDDS>'

위와 같이 설정한 뒤에도 동일하게, 문제가 발생하고 있습니다. 또 다시 발생한 오류 로그를 첨부드립니다.

navigation_오류2.zip (3.0 KB)

해당 코드를 실행한 뒤에 문제가 발생하긴 하는데,

pose.header.stamp = Time(sec=0, nanosec=0) # 수정: time(0) = 항상 최신 TF 사용, 시간 경과와 무관하게 TF 조회 가능

이 코드가 문제일 가능성이 있을까요?

6
  1. WIFI가 아니라 유선으로 연결해도 문제가 발생하는지 확인해보시죠.
    WIFI처럼 불시에 지연이 발생하는 환경에서는 문제가 발생할 수 있습니다.
  2. CPU부하가 생기면 시간 지연이 발생하면서 시간이 틀어질 수 있습니다.
    별도로 실행한 노드나 프로그램이 있는지 살펴 보십시요.