Real robot stuck while explore
Han-IChun opened this issue · comments
Hi
I'm trying Nav2d package on turtlebot3. Base on tutorial3, I replace the Stage node with Turtlebot3 bringup nodes. Everything seems good, but I just can't make the robot explore environment. The robot seems to stuck. It moves very slightly or just spin, shown as below.
I notice that you mention in other post that if the robot just spin but dose not move, we should check the local costmap first so I show /Operator/local_map/costmap on RVIZ. When I use rostopic List, I see another similar topic /Operator/local_costmap. Which one I should use? Except Checking the local costmap, any suggestion to solve the stuck problem?
append parameters for reference.
costmap.txt
mapper.txt
navigator.txt
operator.txt
Thank you,
I-Chun
You can use rqt_graph to show all nodes and topics. I assume that your "/Operator/local_costmap" is there because some other node subscribes to it. The Operator's costmap should be on "/Operator/local_map/costmap".
From looking at your screenshot it could also be that the door is too narrow, so the robot cannot get out of the room. Have a look at the local costmap in RVIZ to see if the robot can fit through the door. If not, you have to decrease the operator's "local_map/robot_radius" parameter.
Hi skasperski :
Thank you so much for suggestions.
The costmap is shown in RVIZ, but it looks very strange. It's like a ring, please see the picture below.
The gray circle area remain the same, no matter what value I use on the robot_radius in costmap.yaml. I tried robot_radius: 0.02. There is no change.
Furthermore, I notice that the costmap does not update. But I have no idea why it doesn't update. Do I use a wrong global frame/ scan frame?
append rqt_graph and rqt_tree here.
Thank you for the reply.
Node-Graph and Transformations seem to be okay, from what I can see. The costmap is really weird. Make sure that you load the costmap parameters in the right place. If you do "rosparam list" you should see the robot radius like this:
/Operator/local_map/robot_radius
I use"rosparam list" , /Operator/local_map/robot_radius is correct and I use "rosparam get /Operator/local_map/robot_radius", it return 0.1. It's exact what I set. However, the gray circle radius in the screen shot is much bigger than 0.1. Is it possible that other .yaml files override this value?
Actually not, because "rosparam get" should get you the parameter, that is actually set and therefor used by the operator. Are there any warnings in rqt_console?
Is your laser mounted higher then 1m? Or is it directly on the floor? Try to change these parameters in your costmap.yaml:
max_obstacle_height: 2.0 # Anything highter then your laser is mounted.
min_obstacle_height: -1.0 # Something negative in case your laser is on hight 0.
Hi skasperski:
I set costmap.yaml as you suggest. The costmap is shown as below.
The laserScan (the white dot) seems in the range between max height and mix height.
I wondering the meaning of colors present in costmap. The deep gray means free space, the rad means collision, the light blue means inflating area and the pink one is obstacle itself. right?
When I use
rosservice call /StartMapping and then
rosservice call /StartExploration
the robot spin and does not move at all, though the navigator give a path.
attach a video:
https://drive.google.com/open?id=0BwW-O8ZbvNdzUjkwd0luQWd1Q1k
The warning message shows in rqt_console:
Node: /Mapper
Time: 09:41:48.170129783 (2017-08-17)
Severity: Warn
Published Topics: /Mapper/edges, /Mapper/vertices, /karto_out, /localization_result, /map, /others, /rosout, /tf
Laser reading not between range_min and range_max!
Location:
/home/ecs/catkin_ws/src/navigation_2d/nav2d_karto/src/MultiMapper.cpp:LocalizedRangeScan* MultiMapper::createFromRosMessage:252
The error message on terminal while the program launch:
I have no idea why this message occur? I use robot_radius parameter not footprint.
Some warning message on roswtf diagnosis:
But it's weird, I don't see any unconnected node in rqt_graph.
Other errors
I notice the / base_scan Transformation in rqt_tf_tree does not update and the topic /Operator/local_map/costmap does not update either.
Hello I-Chun,
I watched the video and it looks okay now. You clearly see that the obstacles and inflation in the costmap is correct.
But in your costmap.txt you have:
footprint: [[-0.205, -0.145], [-0.205, 0.145], [0.077, 0.145], [0.077, -0.145]]
#robot_radius: 0.1
inflation_radius: 1.0
So you commented out the robot radius but set a footprint instead. I don't know why it gives this error, because there are 4 points actually, but maybe this is why the operator cannot work. Try to comment out the footprint and use the radius instead.
You should also check the inflation radius. The inflation radius should be larger then the robot_radius, but not too much. For example, if your robot is 30cm in diameter, set to robot_radius to 0.15~0.20 (to be on the safe side) and if you want it to keep 20 cm away from obstacles if possible , set the inflation_radius to 0.35~0.4.
Best regards,
Sebastian
PS:
About the Warning: "Laser reading not between range_min and range_max!"
This is the reason why you have these large, circular cones of grey area in your global map. This is likely an issue with your laser driver. Please do
rostopic echo --no-arr -c /scan
and have a look at the result. There should be range_min and range_max in it, but the laser seems to provide values out of this range. Maybe there is an option in the turtle-bot driver to set these values correctly.
Hi Sebastian:
Thank you for the suggestions. After some adjustments, the cost map finally work fine and the robot can explore environments autonomously. But there is another problem comes. The map created by Mapper seems skewed. Sometimes, even yield a broken map.
In the picture below, two blue lines should be parallel and both of them are orthogonal to the red line. Is this the problem of setting some parameters too low, such as update_rate or publish_rate?
List parameters I use:
Mapper parameters:
map_update_rate: 6
transform_publish_period: 0.012
costmap parameters:
update_frequency: 2.0
publish_frequency: 0.5
Or Is it transformation accuracy issue?
Thank you,
I-CHUN
Maybe the many max-range readings confuse the mapper a bit. Have you tried to set the max-range in your laser?
And you can try to run the mapper with the parameters from the nav2d_tutorials, these should be quite good for an indoor environment.
I check the topic /scan, the range data contain some 0.0. However, the min and max range is 0.12 and 3.5 respectively. I guess this the reason why the warning continuously shows on rqt_console. Is it a serious problem for Mapper?
I am not completely sure, but it might be. There are a lot of invalid measurements, which can disturb the scan matching algorithm inside the Mapper. (As a little background: The mapper currently treats the 0.0 measurements as readings at range_max, which might be an issue in your case.)
Do you maybe have a bag-file from a test-run with your robot, that you could upload?
Hi skasperski:
Here is a bagfile, record when executing
rosservice call /StartMapping
https://drive.google.com/open?id=0BwW-O8ZbvNdzUXFVVUd5ZVdhZ00
please take a look.
While testing, I find a phenomenon. When robot passes a mono-scene like a straight aisle, the map often fails. The wall orthogonal to the aisle drifts a little and the entrance of that space might drift too. The costmap, laserScan and Map do not consistent at an entrance.
I wonder is it possible that the pure straight aisle confused the localizer so it hardly finds the right position at a current time?
Thank you for every support you provide.
sincerely,
I-CHUN
The robot hardly finds its initial position given a map.
The particlecloud is empty. When I remotely make the robot move, the particlecloud occur all in a sudden, but the particles do not converge. Is my map too featureless to converge? Or is it too ugly to use?? haha
My map is shown below. Please take a look.
Is there any way to improve initial self-localizing performance?
I guess the robot does not get the right initial position then it will fail when planning.
I alway get errors on a terminal.
No way between robot and goal!
Planning failed!
PNG: https://drive.google.com/open?id=0BwW-O8ZbvNdzOGNuVmdQeDRpbzg
YAML: https://drive.google.com/open?id=0BwW-O8ZbvNdzTHJLbXVhZ1JMMW8
Thank you,
I-CHUN
While testing, I find a phenomenon. When robot passes a mono-scene like a straight aisle, the map often fails. The wall orthogonal to the aisle drifts a little and the entrance of that space might drift too. The costmap, laserScan and Map do not consistent at an entrance.
This is actually a pretty common issue. In such a situation, the scan matching inside the mapper can give wrong results, which results in the map distortion that you experienced. This effect is also increased when the odometry has a large error. The solution will be to adapt the scan matching parameters (see here) to avoid false positive matches. All these parameters can be set directly on the mapper node in ROS. Optimizing the mapping for a specific robot system and sensors usually requires some try and error, so bagfiles with just the laser and odometry data for quick testing are your friends! :)
After finishing the setup of a new ROS system, I will also have a look on your bagfile.
The robot hardly finds its initial position given a map.
The particlecloud is empty. When I remotely make the robot move, the particlecloud occur all in a sudden, but the particles do not converge.
Are you navigating on a previously build map or are you using the mapper? Is this another setup, and which localizer are you using, that produces the particle cloud? (The self-localization of the MultiMapper node is only needed in a multi-robot scenario.)
Hi skasperski:
Thank you for guiding me in the right direction of tuning. I'll try to understand how these parameters affect the result of karto Mapper.
I replace Stage node with a real robot bring-up node and use the previously build map created by nav2d_karto( the result of tutorial3 with a real robot) on tutorial2.launch.
Here is the map:
PNG: https://drive.google.com/open?id=0BwW-O8ZbvNdzOGNuVmdQeDRpbzg
YAML: https://drive.google.com/open?id=0BwW-O8ZbvNdzTHJLbXVhZ1JMMW8
The localizer is Nav2d_localizer. When I launch tutorial2 and set navigation goal in RVIZ, The particlecloud is created immediately and converge as robot walks. However, when I use a real robot, the particlecloud is empty and the localizer does not try to match the scan and map. The localizer seems not work. But I don't know why particlecloud is not published.
I'm referring to amcl pkg documentation and hope to get more information. If you can point me in a direction of research that would be great. Thank you very much.
I-CHUN
The "nav2d_localizer" and "amcl" have the same code internally. So each is good to use. Only "amcl" does have some more parameters. Make sure that the localizer is connected with the scan-topic. If it gets no scans, it cannot work.
/scan is connected to the localizer and update well.
When I move the robot physically by hand, sometimes particlecloud would pop up. But they don't converge. Is there any initial condition that has to be satisfied so that the particlecloud can be published?
Hi skasperski,
I did it!!!
The robot could estimate its global position while I set a 2d navigation goal in RVIZ.
One thing is still strange, there was still no particles shows in RIVIZ but the function worked well.
Thank you so much for your time and supports.
Best regards,
I-CHUN