# Adding ultrasonic sensors and range sensor layer

Hello, I need some help with a problem I encountered while adding ultrasonic sensors to a robot (loosely based on Linorobot), already equipped with an RPlidar. Hw/Sw: Raspi3B w/ Ubuntu 16.04.6 LTS, ROS kinetic, a Teensy, 2 Nano.

The robot was working fine with just the lidar, but I need to be able to detect correctly glass and some reflective surfaces, so I'm adding the ultrasonic sensors. The hardware and microcontroller (rosserial) parts seem to be working fine, I suspect it's an error from my part, maybe related to namespaces or transform frames... or maybe I'm missing something gargantuan. I checked and re-checked against online tutorials, examples and other questions similar to this one, but I couldn't identify the culprit.

After executing the launch files I get the standard messages (same as before trying to setup the ultrasonic sensors), plus:

[ INFO] [1631195261.554945536]: global_costmap/sonar_layer: ALL as input_sensor_type given
[ INFO] [1631195261.596176257]: RangeSensorLayer: subscribed to topic /ultrasound_front


and I guess that's good.

Unfortunately from that moment onward I get (with increasingly high figures, of course):

[ WARN] [1631195265.533631740]: No range readings received for 4.02 seconds, while expected at least every 2.00 seconds.


here's a sensor message (from "rostopic echo /ultrasound_front"):

----
seq: 1124
stamp:
secs: 1631192726
nsecs: 301432058
frame_id: "sonar_front"
field_of_view: 0.259999990463
min_range: 0.0
max_range: 100.0
range: 52.0
----


So, the topic is published and the massages should be ok...

My costmap_common_params.yaml:

map_type: costmap

transform_tolerance: 1

footprint: [[-0.25, -0.25], [-0.25, 0.25], [0.25, 0.25], [0.25, -0.25]]

inflation_layer:
cost_scaling_factor: 3

obstacle_layer:
obstacle_range: 2.5
raytrace_range: 3.0
observation_sources: scan
observation_persistence: 0.0
scan:
data_type: LaserScan
topic: scan
marking: true
clearing: true

sonar_layer:
frame: sonar_front
topics: ["/ultrasound_front"]
clear_threshold: 0.2
mark_threshold: 0.80


My global_costmap_params.yaml:

global_costmap:
global_frame: /map
robot_base_frame: /base_footprint
update_frequency: 1
publish_frequency: 0.5
static_map: true
transform_tolerance: 1
plugins:
- {name: static_layer,    type: "costmap_2d::StaticLayer"}
- {name: sonar_layer,   type: "range_sensor_layer::RangeSensorLayer"}
- {name: obstacle_layer,  type: "costmap_2d::ObstacleLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}


My local_costmap_params.yaml:

local_costmap:
global_frame: /odom
robot_base_frame: /base_footprint
update_frequency: 1
publish_frequency: 5.0
static_map: false
rolling_window: true
width: 3
height: 3
resolution: 0.02
transform_tolerance: 1
observation_persistence: 0.0

plugins:
- {name: obstacle_layer,  type: "costmap_2d::ObstacleLayer"}
- {name: sonar_layer, type: "range_sensor_layer::RangeSensorLayer"}
- {name: inflation_layer, type: "costmap_2d::InflationLayer"}


after getting the messages, "rostopic hz /ultrasound_front" gives: (thanks to @miura for the suggestion!)

subscribed to [/ultrasound_front]
average rate: 3.494
min: 0.267s max: 0.305s std dev: 0.01919s window: 3
average rate: 3.384
min: 0.250s max: 0.353s std dev: 0.03533s window: 6
average rate: 3.362
min: 0.250s max: 0.353s std dev: 0.02813s window: 9
average rate: 3.352
min: 0.250s max: 0.353s std dev: 0.02625s window: 13
average rate: 3.349
min: 0.250s max: 0.353s std dev: 0.02447s window: 16
average rate: 3.344
min: 0.250s ...
edit retag close merge delete

1

Have you tried checking the communication cycle with rostopic hz /ultrasound_front? I think you are getting a warning because the communication cycle is slow.

Also, I find it strange that in rostopic echo /ultrasound_front, range is 52.0 while max_range is 1.0. Normally, the range should be smaller than the max_range. If max_range < range persists, I think there is an issue with the sensor.

( 2021-09-09 17:51:41 -0500 )edit
1

Thank you! Updating the question...

( 2021-09-10 04:14:30 -0500 )edit

When I refer to the warning displayed in the terminal and the sensor message, the timestamp is way off. If this is the data when they are running at the same time, then the clock may be out of sync. You may need to set one of the clocks.

Also, it may not be the intended behavior, but if you set no_readings_timeout to 0.0 in costmap_common_params.yaml, it may work.

( 2021-09-10 18:17:25 -0500 )edit
1

Thank you once more miura for the help! The timestamp are different because weren't recorded at the same time, I checked the sync and the timestamp secs in the ultrasound_front topic seems to correspond to the timestamp from the launch file.

I tried setting no_readings_timeout to 0.0, as you suggested, I think it's a step forward, or at least could help identify the problem:
I got this an error from the launch file, every second or so: [ERROR] [1631543292.139093839]: Range sensor layer can't transform from odom to sonar_front at 1631543288.530009 OR same error, but ...from map to sonar_front....

I don't get the "no readings" warning anymore, so I'm currently investigating this other error, to see if I can identify the cause (maybe some problem in the tf tree). In any case I will post/update my findings!

( 2021-09-13 09:41:03 -0500 )edit

Sort by » oldest newest most voted

I finally solved some of the problems that emerged after adding the ultrasound sensors. Because of the nature of the errors, and the extremely large amount of different hw/sw configurations possible, I will put here my findings, with some more general info, hoping to help others:

• Double check the UNIT of MEASURE used in the range fields in the microcontroller code. For example, the library and examples I used and referred to had everything in cm.
This isn't good for ROS navigation layer, the range/distance numbers passed in the messages should be in meters (min_range, max_range, range).
HOWEVER the microcontroller code could be passing the data, and using some internal calculations or logic, in centimeters (like here 'https://www.intorobotics.com/how-to-u...', for example), so some changes are probably needed (also regarding the logic behind the clearing of the costmap, but that's a problem for another question).
• A message rate of 20Hz should be ok, it should not produce missing data messages, sync errors, etc. However please note that it's possible this frequency has to be modified, depending on the hardware involved.
• The costmap YAML parameter clear_on_max_reading behaviour depends on how the data is presented by your ultrasound sensor (or sensors) MCU code. It's a good idea to try both settings and check which one is more appropriate for your case. You can then modify the MCU code to accomodate for the library logic behind this setting (or the other way around, modifying the libraries).
• Verify that your RVIZ configuration contains all the necessary information to visualize your ultrasound (range) sensor data (http://wiki.ros.org/rviz/DisplayTypes...)
• The URDF usually gives clear messages if something related to the transforms and related data is not working, once the real problems are solved, it's possible to see the cones and axes in Rviz (IF the unit of measure isn't too small!), so it's easy to correct orientation and position errors.
• Use check_urdfto verify the validity of the URDF file (http://wiki.ros.org/urdf#Verification), and urdf_to_graphizto have a visual representation with some more data, that could give some clues on malfunctions or errors (http://wiki.ros.org/urdf#Visualization). Also rqt_graph with enable_statisticsset to "true" can give useful clues (http://wiki.ros.org/rqt_graph).
more