skasperski / navigation_2d

ROS nodes to navigate a mobile robot in a planar environment
GNU General Public License v3.0
123 stars 65 forks source link

Getting error No way between robot and goal! when running Exploration (tutorial3) for turtlebot3_burger with Gazebo #59

Closed aditi741997 closed 1 year ago

aditi741997 commented 3 years ago

Hello

I am trying to run tutorial3 with gazebo and turtlebot3_burger - I start a robot_state_publisher node along with gazebo and the navigator/operator/mapper. I am using the turtlebot3_house world for exploration. I have set robot_Radius to 0.3 and map_inflation_Radius to 1.0 in the navigator.yaml file.

I run StartMapping, which runs fine. Then, I run StartExploration. It runs fine for some time, but then I end up getting No way between robot and goal!, and then the exploration fails.

It'd be great if you could help identify the issue - I have also checked the local costmap visualization - it is working.

skasperski commented 3 years ago

The message "No way between robot and goal!" indicates a problem with the navigator or the map. Please check the map (global map from mapper, not costmap_2d from operator) when this error occurs.

aditi741997 commented 3 years ago

Hello, THankyou for your response. Here is the image for the map in gazebo : tb3_nav2d_gazebo_map

Here is the global map as displayed on rviz : tb3_nav2d_rviz_gmap

Here is the local map as displayed on rviz : tb3_nav2d_rviz_lcmp

aditi741997 commented 3 years ago

The global map does seem okay to me, on comparing to the gazebo image. It'd be great if you could help identify the issue. WOuld changing the map resolution or the inflation radius help?

aditi741997 commented 3 years ago

I had another question - is it okay to just explore the map by giving goals to the robot [by publishing on /goal], without running StartMapping or StartExploration at all? Would there be any issues in localization? When I tried it, the robot seemed to reach some nearby goals, and I do see the same error 'No way between robot and goal' for some goals.

skasperski commented 3 years ago

The global map does seem okay to me, on comparing to the gazebo image. It'd be great if you could help identify the issue.

Oh, I have an idea what might be your issue here. The map looks generally fine, but OpenKarto has a strange issue when a mostly rectangular map (like a building floorplan) is drawn exactly parallel with the grid in the map. It can result in outer walls disappearing from the map. Can you change the robot's start pose in the simulation to be rotated by 45° (robot starts in a diagonal direction with regards to the building walls) and check if the issue persists?

skasperski commented 3 years ago

I had another question - is it okay to just explore the map by giving goals to the robot [by publishing on /goal], without running StartMapping or StartExploration at all? Would there be any issues in localization?

No, this should be perfectly fine. Mapping and localization are done within the mapper and are completely independent from the exploration, which is done in the navigator. In fact the exploration-plugin just sets goals for the navigator automaticilly.

aditi741997 commented 3 years ago

https://github.com/skasperski/navigation_2d/issues/59#issuecomment-696565784

I tried setting the orientation to 45 degrees. I get the same error again : ' No way between robot and goal! [ WARN] [1600802152.957382490, 917.306000000]: Exploration has failed! [ WARN] [1600802153.035681773, 917.375000000]: NAV2D : RobotOperator got command : direction 0.000000, velocity 0.000000, MODE : 0 [ WARN] [1600802155.743737636, 919.676000000]: Robot is stuck! Trying to recover...' Here's the picture in gazebo: tb3_nav2d_gz_orient

Also, as can be seen from rviz, the robot took some time going around the walls [in the middle left part of the image] - is that also an artefact of OpenKarto? Here's the rviz image [Note that the weird 'block' in the middle of the rooms is because the white boxes are dynamic obstacles.] tb3_nav2d_rviz_gmap_orient

skasperski commented 3 years ago

Your map is still parallel with the grid. I expected it to look more like in the tutorials, where the robots also start in a diagonal direction. (See images here: http://wiki.ros.org/nav2d/Tutorials/DistributedMapping )

Also your map resolution seems pretty low. Have you tried to use higher resolution?

aditi741997 commented 3 years ago

I tried higher resolution - have set grid_Resolution to 0.05 in mapper.yaml now.

I am setting the initial pose of the robot to be 45 degrees with the walls [im using spawn_model in gazebo_ros, and I specify the yaw], in the previous diagrams. I am not sure why is the map still parallel to the walls - would you know why? Or, another way to get something similar to the tutorial in the gazebo + turtlebot3 setting?

skasperski commented 3 years ago

Did the robot start diagonally in Gazebo? Or do you use some kind of ground-truth localization instead of the pose calculated by the SLAM algorithm?

aditi741997 commented 3 years ago

Yes, the robot is aligned at 45degrees when gazebo simulation starts. Here's the rviz picture that shows that : [robot's orientation is 45deg with the grid in rviz] Screenshot from 2020-09-23 17-04-57 But once I give a goal STartMapping/ StartExploration, the map does end up being parallel to the rviz grid. I am not sure how else to ensure that the map isnt parallel...

skasperski commented 3 years ago

That's exactly the issue. In the map the robot should always start at (0,0) with a yaw of 0, no matter how it is located in the real (or simulated) world. If the robot is aligned with the simulated world from the start, it really seems you are using some ground-truth localization. Can you post the output of "rosrun tf view_frames" ?

aditi741997 commented 3 years ago

I get a segmentation fault if I try to run tf view_Frames, or even if I try to run rosrun rqt_tf_tree rqt_tf_tree, also on tf tf_echo... Is there any other way to visualize the transforms?

skasperski commented 3 years ago

It might also be the case, that the odometry from Gazebo works a little different from the one in Stage in the way that it provides a global position instead of (0,0,0) at the beginning. Maybe you can find an option in Gazebo to initialize the robot's odometry with (0,0,0).

Or if this doesn't work, maybe you can just rotate the environment in Gezebo a bit, this should definitely do the job.

skasperski commented 3 years ago

I get a segmentation fault if I try to run tf view_Frames, or even if I try to run rosrun rqt_tf_tree rqt_tf_tree, also on tf tf_echo... Is there any other way to visualize the transforms?

None that I knew ...

aditi741997 commented 3 years ago

I get a segmentation fault if I try to run tf view_Frames, or even if I try to run rosrun rqt_tf_tree rqt_tf_tree, also on tf tf_echo... Is there any other way to visualize the transforms?

None that I knew ...

I do see the TF tree in rviz as map - odom - offset - base_footprint [which is the robot_frame for tb3] - base_link - [base_Scan (the laser scans are in this frame)], if thats any help?

skasperski commented 3 years ago

You mean map - offset - odom - base_footprint, right?

aditi741997 commented 3 years ago

Yes, sorry - Here's the screenshot from rviz tb3_gz_nav2d_rviz_tf

aditi741997 commented 3 years ago

I had another question [sorry to bother you so muc and thanks for responding!] - I am trying to run nav2d in a relatively-empty gazebo environent now [just to check if the 'no way' error was due to too many obstacles in the envt], and now the exploration sometimes finishes even before exploring the whole map - here's a rviz screenshot. Would you know how to resolve this? [Note that I havent rotated the gazebo envt yet so it also fails sometimes] Screenshot from 2020-09-24 10-35-16

I tried rotating the gz envt to some orientation as well, but the exploration still fails, Here's a screenshot : Screenshot from 2020-09-24 11-43-06

skasperski commented 3 years ago

Exploration is finished when no frontier cell can be reached anymore. You may want to check the robot_radius in the navigator. If it's too large (it should be only a little larger then in the operator), the robot might not reach spots where the map can be expanded.

In your screenshot, it actually did plan a path to the next frontier, as you can see by the pink line.

aditi741997 commented 3 years ago

Exploration is finished when no frontier cell can be reached anymore. You may want to check the robot_radius in the navigator. If it's too large (it should be only a little larger then in the operator), the robot might not reach spots where the map can be expanded.

There is currently no 'robot_Radius' parameter in the operator, are u referring to the costmap.yaml 's inflation_Radius by any chance? Here are my parameters : costmap : inflation_Radius = 0.9 [No robot_Radius in costmap.yaml], And in navigator.yaml, map_inflation_radius: 0.9 and robot_radius: 0.3

In your screenshot, it actually did plan a path to the next frontier, as you can see by the pink line.

Yeah, I saw that, and thats what confused me more - inspite of there being a path, the exploration was finished by the navigator. Would this be resolved by updating the radius parameters?

aditi741997 commented 3 years ago

With regard to setting the right radii, i'd like to mention that I'm using turtlebot3 burger, which is of dimensions 0.140.18, and the footprint in the costmap parameters is set to 0.1460.21, and the inflation radius is 1.0, cost_scaling_Factor is 3.0 [I referred to https://github.com/ROBOTIS-GIT/turtlebot3/blob/master/turtlebot3_navigation/param/costmap_common_params_burger.yaml for these parameters]. Could the issue potentially be due to the fact that the footprint is not actually circular? [when specifying the footprint as in the params file, the center of the robot is assumed to be at 0,0.]