-
Notifications
You must be signed in to change notification settings - Fork 86
/
sick_lms_1xx.launch
112 lines (103 loc) · 11.4 KB
/
sick_lms_1xx.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
<?xml version="1.0"?>
<!-- FOR FUTURE USE. NOT SUPPORTED NOW. DO NOT USE IT. -->
<!-- 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="nodename" default="sick_lms_1xx"/>
<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="encoder_mode" default="-1"/> <!-- Encoder settings (default: -1, i.e. not set): 0: Off, 1: Single increment, 2: Direction recognition phase, 3: Direction recognition level, 4: Fixed increment speed/ticks (LMS4000 only) -->
<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="False"/>
<param name="intensity_resolution_16bit" type="bool" value="false"/>
<param name="min_ang" type="double" value="-2.35619"/>
<param name="max_ang" type="double" value="2.35619"/>
<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_lms_1xx"/>
<!-- 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.05"/>
<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_lidoutputstate" type="bool" value="True"/> <!-- activate field monitoring by lidoutputstate messages -->
<param name="activate_lidinputstate" type="bool" value="True"/> <!-- activate field monitoring by lidinputstate messages -->
<param name="min_intensity" type="double" value="0.0"/> <!-- Set range of LaserScan messages to infinity, if intensity < min_intensity (default: 0) -->
<param name="encoder_mode" type="int" value="$(arg encoder_mode)"/> <!-- Encoder settings (default: -1, i.e. not set): 0: Off, 1: Single increment, 2: Direction recognition phase, 3: Direction recognition level, 4: Fixed increment speed/ticks (LMS4000 only) -->
<param name="scandatacfg_timingflag" type="int" value="-1"/> <!-- Set timing flag LMDscandatacfg (LMS-1XX, LMS-1XXX, LMS-4XXX, LMS-5XX, MRS-1XXX, MRS-6XXX, NAV-2XX, TIM-240, TIM-4XX, TIM-5XX, TIM-7XX, TIM-7XXS): -1: use default (off for TiM-240, otherwise on), 0: do not send time information, 1: send time information -->
<param name="ang_res" type="double" value="0.5" /> <!-- Supported values are "0.25" and "0.50" -->
<param name="scan_freq" type="double" value="50" /> <!-- Supported values are "25" and "50" -->
<!-- Note: angular resolution and scanning frequency of a LMS111 can be configured by parameter "ang_res" (values "0.25" or "0.5") and "scan_freq" (values "25" or "50") -->
<!-- After setting "ang_res" and "scan_freq", it takes ca. 30 seconds until the pointcloud is published. -->
<!-- Recommendation: It is recommended to specify the desired angular resolution and scan rate in this launch file. -->
<!-- In this case, it is necessary to wait approx. 30 sec. until the Lidar changes to status "OK". -->
<!-- Alternatively, these settings can be configured in SOPAS-ET, transferred to the EEProm of the lidar and -->
<!-- then permanently stored. In this case, the explicit specification of scan rate and angular resolution -->
<!-- can be omitted and the waiting time can be avoided. -->
<!-- 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="$(arg add_transform_xyz_rpy)" />
<param name="add_transform_check_dynamic_updates" type="bool" value="$(arg add_transform_check_dynamic_updates)" />
<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 -->
<!--
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>