setup_sensor flag doesn't disable sensor configuration communication

[msz-rai]

According to the README (Generic launch file section), setup_sensor flag should disable sensor configuration communication. It doesn't work in my case. I am running the following command:

ros2 launch nebula_ros nebula_launch.py sensor_model:=PandarQT64 setup_sensor:=false sensor_ip:=127.0.0.1 return_mode:=First

and hesai_hw_interface_ros_wrapper_node is trying to connect with the sensor until successful. I get the following output:

[component_container-1] [INFO] [1712565931.610202378] [hesai_hw_interface_ros_wrapper_node]: SensorConfig:SensorModel: PandarQT64, FrameID: hesai, HostIP: 255.255.255.255, SensorIP: 127.0.0.1, DataPort: 2368, ReturnMode: First, Frequency: 0, MTU: 1500, Use sensor time: 0, GnssPort: 10110, ScanPhase:0, RotationSpeed:600, FOV(Start):0, FOV(End):360, DualReturnDistanceThreshold:0.1, PtpProfile:IEEE_1588v2, PtpDomain:0, PtpTransportType:UDP/IP, PtpSwitchType:TSN
[component_container-1] 127.0.0.1:9347
[component_container-1] [ERROR] [1712565931.610316207] [TcpSocket::open]: Connection refused
[component_container-1] [INFO] [1712565931.610333148] [hesai_hw_interface_ros_wrapper_node]: hesai_hw_interface_ros_wrapper_node Retry: 0
[component_container-1] [ERROR] [1712565939.610506246] [hesai_hw_interface_ros_wrapper_node]: hesai_hw_interface_ros_wrapper_node Retry: 1
[component_container-1] [ERROR] [1712565939.610584644] [TcpSocket::shutdown]: Bad file descriptor
[component_container-1] 127.0.0.1:9347
[component_container-1] [ERROR] [1712565939.610664718] [TcpSocket::open]: Connection refused
[component_container-1] [ERROR] [1712565947.610774567] [hesai_hw_interface_ros_wrapper_node]: hesai_hw_interface_ros_wrapper_node Retry: 2
[component_container-1] [ERROR] [1712565947.610876308] [TcpSocket::shutdown]: Bad file descriptor
[component_container-1] [ERROR] [1712565947.610963187] [TcpSocket::open]: Connection refused
[component_container-1] 127.0.0.1:9347
[component_container-1] [ERROR] [1712565955.611119066] [hesai_hw_interface_ros_wrapper_node]: hesai_hw_interface_ros_wrapper_node Retry: 3
[component_container-1] [ERROR] [1712565955.611211402] [TcpSocket::shutdown]: Bad file descriptor

[mojomex]

Thank you for your issue! There are two types of sensor communication:

• sending settings/values to the sensor, such as return mode, sync angle, etc. (sensor setup)
• getting settings/values/diagnostics from the sensor

While setup_sensor:=false disables the first kind of communication, Nebula still tries to get info from the sensor.
Using launch_hw:=false disables all sensor communication.

I hope this helps! Please let us know when you run into any other issues.

[msz-rai]

Thank you for the response and the clarification 🙇‍♂️

Our use case is to receive from the data port only since we simulate the sensors' point cloud output. I expected that setup_sensor should disable the PTC connection globally. In this case, the solution seems to be setting retry_hw and setup_sensor to false in *_hw_ros_wrapper and not launching *_hw_monitor_ros_wrapper.

[mojomex]

I see, our use case has been slightly different which is what probably caused you issues here.
There is a topic /hesai_packets which is an array of raw UDP packets (+ timestamp) which is published by the HW interface during online operation. For offline operation (playing from Rosbag), we replayed those messages instead of the actual UDP traffic.

If your workaround is good enough for your current use case, I think there is no urgent pressure to 'officially' support it in Nebula yet. If you find there is significant trouble, we are open to reopen the discussion!

Thank you!

[msz-rai]

Thank you for clarifying the situation. At the moment, the workaround seems to be meeting our needs. If any significant issues arise in the future, we'll be sure to reach out to reopen the discussion.

Thanks again for your support and assistance!

[msz-rai]

@mojomex
Unfortunately, the latest driver version does not allow a workaround. I prepared the PR with a new parameter to run the driver in a listen-only mode:
#210