SICKAG / sick_lidar_localization

Apache License 2.0
24 stars 10 forks source link

How to identify multiple Virtual Line sensors output #13

Closed kazuse5 closed 2 years ago

kazuse5 commented 2 years ago

Hello,

I have tested LiDAR-LOC with ROS2.

LineMeasurementMessage0403.msg is bellow.

[INFO] [1647565498.407095608] [sick_lidar_localization]: sick_lidar_localization::UDPReceiverThread: udp message received: LineMeasurementPayload0403:{telegram_count:5598, timestamp:1447439846, num_lanes:1, lanes:[-5], sync_timestamp_sec:0, sync_timestamp_nsec:0, sync_timestamp_valid:0} [INFO] [1647565498.407248206] [sick_lidar_localization]: sick_lidar_localization::UDPReceiverThread: udp message received: LineMeasurementPayload0403:{telegram_count:5598, timestamp:1447439846, num_lanes:1, lanes:[-3], sync_timestamp_sec:0, sync_timestamp_nsec:0, sync_timestamp_valid:0} [INFO] [1647565498.407302820] [sick_lidar_localization]: sick_lidar_localization::UDPReceiverThread: udp message received: LineMeasurementPayload0403:{telegram_count:5598, timestamp:1447439846, num_lanes:1, lanes:[-7], sync_timestamp_sec:0, sync_timestamp_nsec:0, sync_timestamp_valid:0}

With the information, it seems that it is not possible to identify which virtual line sensor each output is.

The sourceID is defined in the configuration file named lidarloc_sample.yml. Would it be possible to add the sourceID to the output ?

Thank you.

tbohnma commented 2 years ago

Hello,

you are right. From the payload alone you cannot distinguish between the sensors. For his use case you have the source ID in the header: image

In your configuration file, in the section of the virtualLine sensor, you configure this Source ID for the output: image

This source ID should be different for the 3 different line sensors.

kazuse5 commented 2 years ago

Hello,

thank you for your reply.

The source ID of 1st virtual line sensor is 101. The 2nd one is 102 and the 3rd one is 103.

We would appreciate it if the sick_lidar_localization driver could be improved so that the source ID is added to the output.

heinrse commented 2 years ago

Hello, As mentioned above, the source ID should already be part of the header of the telegram: image

kazuse5 commented 2 years ago

Hello,

The output format of the sick_lidar_localization ROS driver is described below. https://github.com/SICKAG/sick_lidar_localization/blob/master/msg/LineMeasurementMessage0403.msg

One of the outputs I actually checked is listed below, as I mentioned at the beginning. [INFO] [1647565498.407095608] [sick_lidar_localization]: sick_lidar_localization::UDPReceiverThread: udp message received: LineMeasurementPayload0403:{telegram_count:5598, timestamp:1447439846, num_lanes:1, lanes:[-5], sync_timestamp_sec:0, sync_timestamp_nsec:0, sync_timestamp_valid:0}

In the output, I assume the header part (std_msgs/Header header) is below: sick_lidar_localization::UDPReceiverThread: udp message received: LineMeasurementPayload0403

I expected the header part (std_msgs/Header header) to contain the "source ID". But, it seems that the source ID cannot be found in the header part.

Is this understanding wrong ?

The source IDs of the three virtual line sensors are set to different values.

image

tbohnma commented 2 years ago

Hello,

you mention the payload output in the console. You see only the payload because only the payload has a print template: sick_lidar_localization::UDPMessage::printPayload

(from https://github.com/SICKAG/sick_lidar_localization/blob/master/src/udp_message_parser.cpp)

But in the actual programming in ROS or C++ you have to access the whole message by a listener including the header.

Does this make sense or am I missing something?