Visual_slam_node Frame Delta Warnings Slightly Above Threshold (e.g., 34.4ms > 34.0ms) in People Detection Mode with RealSense

Robotics & Edge Computing Robotics - Isaac Isaac ROS
1

Hi NVIDIA Isaac ROS team,

I’m using the [b]isaac_ros_visual_slam[/b] package with the [i]realsense_example.launch.py[/i] file from [i]nvblox_examples_bringup[/i], running in [b]mode:=people_detection[/b]. The SLAM node (visual_slam_node) consistently outputs warnings like the following:

[visual_slam_node]: Delta between current and previous frame [34.164736 ms] is above threshold [34.000000 ms]
[visual_slam_node]: Delta between current and previous frame [34.333952 ms] is above threshold [34.000000 ms]
[visual_slam_node]: Delta between current and previous frame [34.438400 ms] is above threshold [34.000000 ms]

🔍 Setup Details:
[list]
[]ROS 2 Humble
[]Isaac ROS 2024.1 release
[]RealSense D435i camera
[]RealSense FPS set to 30 (640x480 @ 30)
[]Using visual_slam_node in the provided launch structure
[]Running on GPU (Jetson Orin / x86 with NVIDIA GPU)
[*]Running live sensor (not rosbag)
[/list]

✅ What I’ve Tried:
[list]
[*]FPS is locked at 30 (verified via rqt)
[*]enable_sync:=True for RealSense
[*]–log-level warn does not suppress these warnings
[*]Modified vslam.launch.py to set max_frame_delta_time_ms = 50.0, but warnings still appear
[*]The actual deltas are only slightly above 34 ms (e.g., 34.2–34.4 ms)
[/list]

❓ My Question:
[list]
[*]Is there a default hardcoded threshold of 34.0 ms still being enforced?
[*]Does max_frame_delta_time_ms actually take effect when passed as a node parameter in the launch file?
[]Is there a better way to handle this frame jitter for a 30 FPS camera?
[]Would it be possible to officially support a small tolerance window (e.g., ±1 ms) to suppress false positives?
[/list]

Thanks in advance! Any guidance or clarification would be appreciated.

Best regards,
Abhishek

2

Hi @chaud324

Thanks for your message,

This message is a warning that some frames arrive late compared to the threshold of 34ms.
The reasons can be multiple, from the software running on your device.

Yes, you can change, the parameter is: image_jitter_threshold_ms

Acceptable time delta between consecutive synced image messages. If the messages exceed the threshold, it might be an indication of message drop from the source.

Which parameter have you tried? I was looking for this parameter, but I don’t see in the Isaac ROS vslam package.

I checked for other options, and it seems you are on the right track.

I will check if there are other ways, and I will keep you posted.

Best,
Raffaello