-
Notifications
You must be signed in to change notification settings - Fork 87
/
sick_lrs_36x1_upside_down.launch
119 lines (109 loc) · 11.2 KB
/
sick_lrs_36x1_upside_down.launch
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
<?xml version="1.0"?>
<!-- Using node option required="true" will close roslaunch after node exits -->
<launch>
<arg name="hostname" default="192.168.0.1"/>
<arg name="cloud_topic" default="cloud"/>
<arg name="laserscan_topic" default="scan"/>
<arg name="frame_id" default="cloud"/>
<arg name="sw_pll_only_publish" default="True"/>
<arg name="scan_cfg_list_entry" default="1"/>
<arg name="skip" default="0"/>
<arg name="nodename" default="sick_lrs_36x1"/>
<arg name="add_transform_xyz_rpy" default="0,0,0,0,0,0"/>
<arg name="add_transform_check_dynamic_updates" default="false"/> <!-- Note: dynamical updates of parameter add_transform_xyz_rpy can decrease the performance and is therefor deactivated by default -->
<arg name="tf_publish_rate" default="10.0" /> <!-- Rate to publish TF messages in hz, use 0 to deactivate TF messages -->
<node name="$(arg nodename)" pkg="sick_scan_xd" type="sick_generic_caller" respawn="false" output="screen" required="true">
<param name="intensity" type="bool" value="True"/>
<param name="frame_id" type="str" value="$(arg frame_id)"/>
<param name="use_binary_protocol" type="bool" value="True"/>
<param name="scanner_type" type="string" value="sick_lrs_36x1"/>
<!-- Optional range filter configuration: If the range of a scan point is less than range_min or greater than range_max, the point can be filtered. -->
<!-- Depending on parameter range_filter_handling, the following filter can be applied for points with a range not within [range_min, range_max], -->
<!-- see enumeration RangeFilterResultHandling in range_filter.h: -->
<!-- 0: RANGE_FILTER_DEACTIVATED, do not apply range filter (default) -->
<!-- 1: RANGE_FILTER_DROP, drop point, if range is not within [range_min, range_max] -->
<!-- 2: RANGE_FILTER_TO_ZERO, set range to 0, if range is not within [range_min, range_max] -->
<!-- 3: RANGE_FILTER_TO_RANGE_MAX, set range to range_max, if range is not within [range_min, range_max] -->
<!-- 4: RANGE_FILTER_TO_FLT_MAX, set range to FLT_MAX, if range is not within [range_min, range_max] -->
<!-- 5: RANGE_FILTER_TO_NAN set range to NAN, if range is not within [range_min, range_max] -->
<!-- Note: Range filter applies only to Pointcloud messages, not to LaserScan messages. -->
<!-- Using range_filter_handling 4 or 5 requires handling of FLT_MAX and NAN values in an application. -->
<param name="range_min" type="double" value="0.0"/>
<param name="range_max" type="double" value="25.0"/>
<param name="range_filter_handling" type="int" value="0"/>
<param name="hostname" type="string" value="$(arg hostname)"/>
<param name="cloud_topic" type="string" value="$(arg cloud_topic)"/>
<param name="laserscan_topic" type="string" value="$(arg laserscan_topic)"/>
<param name="port" type="string" value="2112"/>
<param name="timelimit" type="int" value="5"/>
<param name="sw_pll_only_publish" type="bool" value="$(arg sw_pll_only_publish)"/>
<param name="use_generation_timestamp" type="bool" value="true"/> <!-- Use the lidar generation timestamp (true, default) or send timestamp (false) for the software pll converted message timestamp -->
<param name="start_services" type="bool" value="True"/> <!-- start ros service for cola commands -->
<param name="activate_lferec" type="bool" value="True"/> <!-- activate field monitoring by lferec messages -->
<param name="activate_lidinputstate" type="bool" value="False"/>
<param name="activate_lidoutputstate" type="bool" value="False"/>
<param name="scan_cfg_list_entry" type="int" value="$(arg scan_cfg_list_entry)"/> <!-- only mode 1 is currently supported -->
<param name="skip" type="int" value="$(arg skip)"/> <!-- Default: 0 (i.e. publish each scan), otherwise only each n.th scan is published -->
<param name="min_ang" type="double" value="-3.141592"/> <!-- default start angle for LRS 36x1: 0 deg, please do not change -->
<param name="max_ang" type="double" value="3.141592"/> <!-- default stop angle for LRS 36x1: 360 deg, please do not change -->
<!-- Apply an additional transform to the cartesian pointcloud, default: "0,0,0,0,0,0" (i.e. no transform) -->
<!-- Note: add_transform_xyz_rpy is specified by 6D pose x, y, z, roll, pitch, yaw in [m] resp. [rad] -->
<!-- It transforms a 3D point in cloud coordinates to 3D point in user defined world coordinates: -->
<!-- add_transform_xyz_rpy := T[world,cloud] with parent "world" and child "cloud", i.e. P_world = T[world,cloud] * P_cloud -->
<!-- The additional transform applies to cartesian lidar pointclouds and visualization marker (fields) -->
<!-- It is NOT applied to polar pointclouds, radarscans, ldmrs objects or other messages -->
<param name="add_transform_xyz_rpy" type="string" value="0,0,0,3.141592,0,0" />
<param name="add_transform_check_dynamic_updates" type="bool" value="$(arg add_transform_check_dynamic_updates)" />
<param name="start_services" type="bool" value="True" /> <!-- Start ros service for cola commands, default: true -->
<param name="message_monitoring_enabled" type="bool" value="True" /> <!-- Enable message monitoring with reconnect+reinit in case of timeouts, default: true -->
<param name="read_timeout_millisec_default" type="int" value="5000"/> <!-- 5 sec read timeout in operational mode (measurement mode), default: 5000 milliseconds -->
<param name="read_timeout_millisec_startup" type="int" value="120000"/> <!-- 120 sec read timeout during startup (sensor may be starting up, which can take up to 120 sec.), default: 120000 milliseconds -->
<param name="read_timeout_millisec_kill_node" type="int" value="150000"/> <!-- 150 sec pointcloud timeout, ros node will be killed if no point cloud published within the last 150 sec., default: 150000 milliseconds -->
<!-- Note: read_timeout_millisec_kill_node less or equal 0 deactivates pointcloud monitoring (not recommended) -->
<param name="client_authorization_pw" type="string" value="F4724744"/> <!-- Default password for client authorization -->
<!-- Configuration of ROS quality of service: -->
<!-- On ROS-1, parameter "ros_qos" sets the queue_size of ros publisher -->
<!-- On ROS-2, parameter "ros_qos" sets the QoS of ros publisher to one of the following predefined values: -->
<!-- 0: rclcpp::SystemDefaultsQoS(), 1: rclcpp::ParameterEventsQoS(), 2: rclcpp::ServicesQoS(), 3: rclcpp::ParametersQoS(), 4: rclcpp::SensorDataQoS() -->
<!-- See e.g. https://docs.ros2.org/dashing/api/rclcpp/classrclcpp_1_1QoS.html#ad7e932d8e2f636c80eff674546ec3963 for further details about ROS2 QoS -->
<!-- Default value is -1, i.e. queue_size=10 on ROS-1 resp. qos=rclcpp::SystemDefaultsQoS() on ROS-2 is used.-->
<param name="ros_qos" type="int" value="-1"/> <!-- Default QoS=-1, i.e. do not overwrite, use queue_size=10 on ROS-1 resp. qos=rclcpp::SystemDefaultsQoS() on ROS-2 -->
<!--
|Mode |Inter-laced |Scan freq. | Result. scan freq.| Reso-lution |Total Resol. | Field of view| Sector| LRS 3601 3611 |OEM 1501|NAV 310 |LRS 3600 3610 |OEM 1500|
| | | | | | | | | | | | | |
|1 |0x |8 Hz |8 Hz |0.25° |0.25° |360° |0 ... 360° |x |x |x |(x)|(x)|
|2 |0x |15 Hz |15 Hz |0.5° |0.5° |360° |0 ... 360° |x |x |x |(x)|(x)|
|3 |0x |10 Hz |10 Hz |0.25° |0.25° |300° |30 ... 330° |x |x |x |x |x |
|4 |0x |5 Hz |5 Hz |0.125° |0.125° |300° |30 ... 330° |x |x |x |x |x |
|5 |0x |6 Hz |6 Hz |0.1875° |0.1875° |360° |0 ... 360° |x |x |x |(x)|(x)|
|6 |0x |8 Hz |8 Hz |0.25° |0.25° |359.5° |0.25° ...359.25° | | | |x |X |
|8 |0x |15 Hz |15 Hz |0.375° |0.375° |300° |30...330° |x |X |x |x |x |
|9 |0x |15 Hz |15 Hz |0.5° |0.5° |359° |0.5 ... 359.5° | | | |x |x |
|21 |0x |20 Hz |20 Hz |0.5° |0.5° |300° |30 ... 330° | |X |x | |x |
|22 |0x |20 Hz |20 Hz |0.75° |0.75° |360° |0 ... 360° | |x |x | |(x)|
|44 |4x |10 Hz |2.5 Hz |0.25° |0.0625° |300° |30 ... 330° |x |x | |(x)|(x)|
|46 |4x |16 Hz |4 Hz |0.5° |0.125° |300° |30 ... 330° | |x | | |(x)|
-->
<!--
On ROS-1 and ROS-2, sick_scan_xd publishes TF messsages to map a given base frame (i.e. base coordinates system) to the lidar frame (i.e. lidar coordinates system) and vice versa.
The default base frame id is "map" (which is the default frame in rviz).
The default 6D pose is (x,y,z,roll,pitch,yaw) = (0,0,0,0,0,0) defined by position (x,y,z) in meter and (roll,pitch,yaw) in radians.
This 6D pose (x,y,z,roll,pitch,yaw) is the transform T[base,lidar] with parent "base" and child "lidar".
For lidars mounted on a carrier, the lidar pose T[base,lidar] and base frame can be configured in this launchfile using the following parameter.
The lidar frame id given by parameter "frame_id" resp. "publish_frame_id".
Note that the transform is specified using (x,y,z,roll,pitch,yaw). In contrast, the ROS static_transform_publisher uses commandline arguments in order (x,y,z,yaw,pitch,roll).
-->
<param name="tf_base_frame_id" type="string" value="map" /> <!-- Frame id of base coordinates system, e.g. "map" (default frame in rviz) -->
<param name="tf_base_lidar_xyz_rpy" type="string" value="0,0,0,0,0,0" /> <!-- T[base,lidar], 6D pose (x,y,z,roll,pitch,yaw) in meter resp. radians with parent "map" and child "cloud" -->
<param name="tf_publish_rate" type="double" value="$(arg tf_publish_rate)" /> <!-- Rate to publish TF messages in hz, use 0 to deactivate TF messages -->
<!--
Optional mode to convert lidar ticks to ros- resp. system-timestamps:
tick_to_timestamp_mode = 0 (default): convert lidar ticks in microseconds to system timestamp by software-pll
tick_to_timestamp_mode = 1 (optional tick-mode): convert lidar ticks in microseconds to timestamp by 1.0e-6*(curtick-firstTick)+firstSystemTimestamp
tick_to_timestamp_mode = 2 (optional tick-mode): convert lidar ticks in microseconds directly into a lidar timestamp by sec = tick/1000000, nsec = 1000*(tick%1000000)
Note: Using tick_to_timestamp_mode = 2, the timestamps in ROS message headers will be in lidar time, not in system time. Lidar and system time can be very different.
Using tick_to_timestamp_mode = 2 might cause unexpected results or error messages. We recommend using tick_to_timestamp_mode = 2 for special test cases only.
-->
<param name="tick_to_timestamp_mode" type="int" value="0"/>
</node>
</launch>