ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange
Ask Your Question
0

Navigation goals not working with laser, sonar and slam_toolbox

asked 2023-01-31 14:19:31 -0600

maurizio gravatar image

updated 2023-01-31 16:38:02 -0600

Hi there,

my platform is an "almost turtlebot4": we have a create3 platform with a lidar and an array of 7 ultrasound sensors. For navigating we use the turtlebot4 stack (Ros-Galactic). More specifically we can

CONFIG1. build a map with slam toolbox launching the following configuration:

ros2 launch turtlebot4_navigation nav_bringup.launch.py slam:=async  base_frame:=base_link params_file:=my_robot.yaml

CONFIG2. correctly (and by that I mean navigating using both laser and sonar) navigate the built map (previously obtained by CONFIG1) with the following command:

ros2 launch turtlebot4_navigation nav_bringup.launch.py slam:=off localization:=true  base_frame:=base_link map:=$PWD/the_map_create_at_point1.yaml params_file:=my_robot.yaml

CONFIG3: temporarily obtain the desired behavior until a pose estimate is issued by RVIZ2

ros2 launch turtlebot4_navigation nav_bringup.launch.py slam:=synclocalization:=true  base_frame:=base_link map:=$PWD/the_map_create_at_point1.yaml params_file:=my_robot.yaml

However, when using CONFIG1 (with the slam parameter either set to async or sync) I can not launch navigation goals. The controller server ĺog shows the following (notice that the tf clearly states the relation between the following frames and it is the same in all configs):

LOG_ERROR:

"Range sensor layer can't transform from odom to sonarX_frame", where X=[1,7]

In CONFIG2 there are no problems in launching navigation goals (but obviously we have the drawback of not building a map). Interestingly if I mix slam and localization (configuration CONFIG3)  I can see the robot building a map and accepting navigation goals. This works until I set pose by the RVIZ2 interface (at that moment, if I get it right, amcl and slam_toolbox will concurrently update the robot position and hence the flickering..).

Notice that with CONFIG1, the goal navigation can be issued if I remove the sonar layer. Looking a LOG_ERROR above, is it a problem of slam toolbox not handling other sensors than laser scanner  or most likely I did not understand which configuration would give me the 3 features right below I am looking for?

  • F1. build a map
  • F2. issue navigation goals
  • F3. navigate taking into account scan and sonar readings (in terms of planning / obstacle avoidance)

You find attached the robot configuration file where I have added the sonar layer, here below a "summary" of the config

  • CONFIG1: it builds the map in any case BUT navigation goals work only if I remove the "sonar_layer" from my_robot_config.yaml.
  • CONFIG2: it allows the robot to navigate taking into account both laser and sonar readings
  • CONFIG3: it gives me F1+F2+F3 till I set a robot pose in RVIZ, at that point the robot position estimates start to flicker (probably due to concurrent update).

Thanks

File: my_robot_config.yaml ( I am reporting only the part with the sonar layer as copying the entire file does not work in terms for formatting)

local_costmap:
  local_costmap:
    ros__parameters:
      update_frequency: 5.0
      publish_frequency: 2.0
      global_frame: odom
      robot_base_frame: base_link
      use_sim_time: True
      rolling_window: true
      width: 3
      height: 3
      resolution: 0.05
      robot_radius: 0.22
      plugins: ["obstacle_layer", "sonar_layer", "inflation_layer" ]
      inflation_layer:
        plugin: "nav2_costmap_2d::InflationLayer"
        cost_scaling_factor: 3.0
        inflation_radius ...
(more)
edit retag flag offensive close merge delete

Comments

This is honestly very difficult to read, but the error seems clear: something's up with your TF tree. Unfortunately Galactic is EOL last year so there's no more support from it from Nav2's side, its a dead branch.

Check your URDF and check your TF tree when running in problematic configurations and make sure there's a timely transform possible from your odom to your sensor frames defined in the incoming sonar messages.

stevemacenski gravatar image stevemacenski  ( 2023-01-31 16:08:43 -0600 )edit

Thanks for the reply: I don't think the TF is the problem (the tf should be the same in CONFIG1/CONFIG2/CONFIG3. Look at the frames.pdf that I am attaching. It seems the sonar frames can be expressed w.r.t. base link

maurizio gravatar image maurizio  ( 2023-01-31 16:30:10 -0600 )edit

Now you should see the graph (at the very bottom of the post): laser_frame and sonar_frame (and children) are linked to base_link. The very same tf works in CONFIG3, but in CONFIG2no topic under /local_map can be produced. Also I can see, in CONFIG2, the sonar readings w.r.t. to the robot while navigating... When having localization:=false, who takes care of the localization? Is there a particular node I should look at with rqt_graph? I am asking cause when launching with localization:=true the graph is different and /local_map subtopics are populated, I can see the costmaps and related updates

maurizio gravatar image maurizio  ( 2023-01-31 16:43:05 -0600 )edit

2 Answers

Sort by » oldest newest most voted
0

answered 2023-02-01 15:19:45 -0600

It sounds like config 2 is the only one that contains the sonars? Then its not surprising that's the only one that contains errors w.r.t. the range (sonar) layer... I'm not sure the other detail is necessary. Look into the error in more detail and the messages. Is the frame in the TF tree actually the frame being sent in the sonar messages that its trying to transform? This sounds like you didn't populate the header of your sonar messages

edit flag offensive delete link more

Comments

See my reply above, cause it doesn't fit as a comment

maurizio gravatar image maurizio  ( 2023-02-17 03:26:17 -0600 )edit
0

answered 2023-02-17 03:25:16 -0600

maurizio gravatar image

Sorry for the late reply. No they all do, the layer is involved in populating local_map. You are pointing to interesting things:

You are right that the problem description is "dense" but I could not find better non-graphical ways

"When having localization:=false, who takes care of the localization?" -> I can see that AMCL is taking care of it (and to my understanding it is the "alternative stand-alone" localization). In the Turtlebot4 configuration file it should be launched after going the "if-else" logical flow

The headers are populated, notice that I can see in Rviz the sonar and the local map correctly populated in the "working" configuration. The only doubt I had was whether it was a good thing to setup the "sonar frames" via static transforms rather than in the urdf file, but keep reading down :)

I think I have solved the problem making a tighter sync ( I forgot to mention that the robot-base streams data to a raspberry pi which publishes all the related topics while my laptop - i7 32gbRam ++ let's not worry about this - performs all the navigation tasks, including slam). I have used chrony and by this the error mentioned in the initial question ("Range sensor layer can't transform from odom to sonarX_frame", where X=[1,7]") gets much less frequent (once every 5s may be). In this situation I can issue navigation goals to the robot while it is mapping. The trigger that made me use chrony was that the tf really went bananas over time (I could only see static_tf when using the view_frames utility .. and it happens only in the "problematic configuration", does it mean the traffic is too much for the network? I don't know.. ). I am not yet fully happy cause it doesn't seem to be fully under control.. but I will test it further. There is something.. just to be sure take a look at this question

it is related to your question in bold above: if I get it right, slam_toolbox comes with its own localization part (i.e. it is alternative to the amcl node - I am back to robotics after several years and at that time, in Ros1, I was used to gmapping + amcl + blabla), right?

Thanks again for the help

edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2023-01-31 14:19:31 -0600

Seen: 689 times

Last updated: Feb 17 '23