move_base dies when I publish range data to the range_sensor_layer
I am using a turtlebot3burger with kinetic and Ubuntu 18.04.2 LTS with melodic on my laptop. I connected two sonic sensors (HC-SR04) to the raspberry and wrote a driver to publish the range data. I can map the space and then use the navigation stack to navigate; however, once I turn on these sonic sensors they kill the movebase. I have published them to an alternative topic to see if the hardware was the problem, and they don't interfere with move_base until I publish the range data to the topics I have listed for the plugin. I have tried to figure out why and I'm just not seeing my error. Can anyone help?
error message (although the log file doesn't actually exist when I try to find it):
[move_base-4] process has died [pid 17199, exit code 127, cmd /opt/ros/melodic/lib/move_base/move_base
[WARN] [1556908330.052460]: Failed to get param: timeout expired │ cmd_vel:=/cmd_vel
odom:=odom __name:=move_base __log:=/home/tyrel/.ros/log/b4efff2c-6dd1-11e9-8231-a0
[INFO] [1556908330.056455]: Setup TF on Odometry [odom] │c5890be7a3/move_base-4.log].
[INFO] [1556908330.060261]: Setup TF on IMU [imu_link] │log file: /home/tyrel/.ros/log/b4efff2c-6dd1-11e9-8231-a0c5890be7a3/move_base-4*.log
the log file doesn't exist:
:~/.ros/log/b4efff2c-6dd1-11e9-8231-a0c5890be7a3$ ls
amcl-3-stdout.log map_server-2-stdout.log master.log robot_state_publisher-1-stdout.log roslaunch-urithiru-17109.log
roslaunch-urithiru-17159.log rosout-1-stdout.log rosout.log rviz-5-stdout.log
costmapcommonparams_burger.yaml
1 obstacle_range: 3.0
2 raytrace_range: 3.5
3
4 footprint: [[-0.105, -0.105], [-0.105, 0.105], [0.041, 0.105], [0.041, -0.105]]
5 #robot_radius: 0.105
6
7 inflation_radius: 1.0
8 cost_scaling_factor: 3.0
9
10 max_obstacle_height: 0.6
11 min_obstacle_height: 0.0
12
13 obstacle_layer:
14 observation_sources: scan
15 scan:
16 data_type: LaserScan
17 topic: scan
18 marking: true
19 clearing: true
20 expected_update_rate: 0.0
21 observation_persistence: 0.0
22
23 range_sensor_layer:
24 ns: /sensors/sonar_sensor
25 topics: ["/range_data/front_bumper","/range_data/back_bumper"]
26 no_readings_timeout: 0.0
27 clear_threshold: 1.0
28 mark_threshold: 8.0
29 clear_on_max_reading: true
globalcostmapparams.yaml
1 global_costmap:
2 global_frame: map
3 robot_base_frame: base_footprint
4 map_type: costmap
5 static_map: true
6 rolling_window: false
7 resolution: 0.1
8 update_frequency: 2.0
9 publish_frequency: 2.0
10 transform_tolerance: 3.0
11
12 plugins:
13 - {name: static_layer, type: 'costmap_2d::StaticLayer'}
14 - {name: inflation_layer, type: 'costmap_2d::InflationLayer'}
localcostmapparams.yaml
1 local_costmap:
2 global_frame: odom
3 robot_base_frame: base_footprint
4
5 update_frequency: 2.0
6 publish_frequency: 2.0
7 transform_tolerance: 3.0
8
9 static_map: false
10 rolling_window: true
11 width: 3
12 height: 3
13 resolution: 0.05
14
15 plugins:
16 - {name: range_sensor_layer, type: "range_sensor_layer::RangeSensorLayer"}
17 - {name: obstacle_layer, type: "costmap_2d::ObstacleLayer"}
18 - {name: inflation_layer, type: 'costmap_2d::InflationLayer'}
range data publishing driver
sonic_pub = rospy.Publisher('/range_data/%s_bumper' % name, Range, queue_size=50)
data = Range()
data.radiation_type = 0 #ultrasound
data.field_of_view = 0.5
data.min_range = 0.01
data.max_range = 1.0
r = rospy.Rate(1)
try:
while not rospy.is_shutdown():
GPIO.output(t_pin, True)
time.sleep(0.00001)
GPIO.output(t_pin, False)
while GPIO.input(e_pin)==0:
pulse_start=time.time()
while GPIO.input(e_pin)==1:
pulse_end=time.time()
pulse_duration = pulse_end - pulse_start
distance = pulse_duration * 171.5 #speed of sound at sea level is 343m/s
data.header.stamp = rospy.Time.now()
data.header.frame_id = "%s_sonic_bumper" % name
data.range = distance
sonic_pub.publish(data)
r.sleep()
which gives:
header:
seq: 2
stamp:
secs: 1556907493
nsecs: 388175010
frame_id: "front_sonic_bumper"
radiation_type: 0
field_of_view: 0.5
min_range: 0.00999999977648
max_range: 1.0
range: 2.23068761826
---
Asked by Tyrel on 2019-05-03 14:08:23 UTC
Comments
Just an observation, but this doesn't seem right:
Note how
max_range < range
.Asked by gvdhoorn on 2019-05-04 04:37:47 UTC
I was under the impression that the navigation stack dealt/deleted data outside of the ranges since:
clear_on_max_reading: true
is set.Asked by Tyrel on 2019-05-05 22:24:11 UTC
That could be, but right now you're publishing messages that are malformed. That would be something to fix regardless of who your consumers are (or what they are doing with the messages).
Asked by gvdhoorn on 2019-05-06 00:20:33 UTC
Good point. Thank you.
Asked by Tyrel on 2019-05-06 00:23:30 UTC
@Tyrel Have you solved your problem? I have a very similar problem. My range data is between min and max range. But when I publish on range_sensor topic, the move_base dies.
Asked by VitorHirozawa on 2019-06-11 17:50:54 UTC
@VictorHirozawa Not yet. Let me know if you figure anything out. I'd love to solve this.
Asked by Tyrel on 2019-06-12 00:28:23 UTC
@Tyrel For sure. I will let you know if I solve this issue.
Asked by VitorHirozawa on 2019-06-12 08:56:16 UTC