Issues with Ouster LiDAR sensor.launch: sensor::poll_client() Errors and UDP bad length Packets

Software
1

Hello everyone,

I am currently integrating an Ouster LiDAR with ROS using the provided sensor.launch file, but I am running into persistent connection and packet issues. I’d like to check if anyone has experienced something similar, or if there are known fixes.

System Setup

  • Sensor model: Ouster OS1 (Ethernet connection)

  • ROS version: Noetic

  • Ouster ROS driver: ouster_ros (nodelet-based)

  • Network configuration:

    • Sensor hostname: 192.168.80.55

    • PC (UDP destination): 192.168.80.70

    • LiDAR port: 7502

    • IMU port: 7503

Launch File Snippet

<arg name="sensor_hostname" default="192.168.80.55"/>
<arg name="udp_dest" default="192.168.80.70"/>
<arg name="lidar_port" default="7502"/>
<arg name="imu_port" default="7503"/>
<arg name="lidar_mode" default="1024x10"/>
<arg name="timestamp_mode" default="TIME_FROM_INTERNAL_OSC"/>

Observed Errors

  1. In ROS log:
[ERROR] [..]: maximum number of allowed errors from sensor::poll_client() reached, performing self reset..
  1. With tcpdump:
UDP, bad length 12544 > 1472  (port 7502, LiDAR packets)
UDP, length 48                (port 7503, IMU packets - looks normal)
  1. ROS nodelets eventually reset, and data is not stable.

What I’ve Tried

  • Verified IP addresses and subnet mask (both sensor and PC are reachable by ping).

  • Ensured lidar_port and imu_port match between sensor and driver.

  • Disabled ModemManager and added user to dialout group.

  • Suspect this may be related to MTU size or GRO/LRO offloading on the NIC, but not sure how best to configure for Ouster packets.

Questions

  • Has anyone seen the bad length > 1472 issue with Ouster LiDAR UDP packets?

  • Should the NIC MTU be set to 9000 (jumbo frames) or forced to 1500?

  • Is it recommended to disable GRO/LRO offloading for reliable operation?

  • Are there known “safe” defaults for timestamp_mode, lidar_mode, and udp_profile_lidar to avoid packet mismatches?

Any advice, especially from those who have resolved similar poll_client() timeout/reset issues, would be greatly appreciated!

Thanks in advance.

2

Hi @changkeun

I don’t see issue with how you are configuring the ROS driver. The suggests that some how you are getting a Lidar packet with a size that is different from what we expect. This likely happening due to another device on your network using the same port and sending packets to the machine you are running hte driver on.

I suggest that you either try a different port (try 7505 for example instead of 7502) or try to find which device on your network is using this port (remove the sensor and check the source ip of the packet with the 1472 size ).

Has anyone seen the bad length > 1472 issue with Ouster LiDAR UDP packets?

Usually happens when a different device is using the same port

> Should the NIC MTU be set to 9000 (jumbo frames) or forced to 1500?

The default MTU size of 1500 should be fine.

Are there known “safe” defaults for timestamp_mode, lidar_mode, and udp_profile_lidar to avoid packet mismatches?

All of these options should work, no need to having to pick a specific value.

1 Like
3

1000026847
10000268471177×888 314 KB

Hello, thank you for your reply.

I haven’t tried changing the port yet,

but to share the exact cause of the issue,

I’m sharing a screen capture.

Thank you.