Ask Your Question
0

Configure move_base using ONLY hector_mapping

asked 2020-01-18 07:28:18 -0600

jjggmm gravatar image

updated 2020-01-25 08:07:20 -0600

Hello everyone,

First of all, i want to apologyze if i make any syntax flaws, i dont usually write English.

I am new to ROS and i'm trying to develop a little autonomous car with the only sensor RPLidar.

I'm trying to configurate Navigation Stack pkg using only hector_mapping since i dont have IMU or other sensors that give odometry of the car. I have read multiple posts where people try the to do the same, and they finally get it but unlucky they dont explain how.

I've read that hector_mapping can publish odometry using the following arg: pub_map_odom_transform to True also it can be published using the undocumented param: pub_odometry in the topic: scanmatcher_frame

I've already configured hector_slam to record and save a map with map_saver. And configured hector_mapping with the params mentioned above. Checking the topic list i see that hector_mapping is publishing in the topics: poseupdate, slam_out_pose, tf , scanmatcher_frame and map

The first question, which topic contains the odometry that move_base will use to work? I,ve read that is tf but i've doubts.

I have also read that you dont need to use AMCL if you are using hector_mapping to run Navigation stack, am i wrong?

Assuming that for now everything is fine, the errors must be in the params .yaml files i am using to configure move_base. I dont really know how to fill all the args properly. I am going to paste the code of each one and ask the doubts i have:

base_local_planner_params.yaml

TrajectoryPlannerROS:
  max_vel_x: 0.45
  min_vel_x: 0.1
  max_vel_theta: 1.0
  min_in_place_vel_theta: 0.4

  acc_lim_theta: 3.2
  acc_lim_x: 2.5
  acc_lim_y: 2.5

  holonomic_robot: true

costmap_common_params.yaml

obstacle_range: 2.5
raytrace_range: 3.0
footprint: [[-0.31, -0.69], [-0.31, 0.25], [0.31, 0.25], [0.31, -0.69]]
#robot_radius: ir_of_robot
inflation_radius: 0.55

observation_sources: laser_scan_sensor

laser_scan_sensor: {sensor_frame: laser_frame, data_type: LaserScan, topic: scan, marking: true, clearing: true}

The footprint arg i dont really know what means, may someone explain it please? I have just copied some values i have seen in other post.

global_costmap_params.yaml

global_costmap:
  global_frame: map
  robot_base_frame: base_link
  update_frequency: 5.0
  static_map: true

local_costmap_params.yaml

local_costmap:
  global_frame: odom
  robot_base_frame: base_link
  update_frequency: 5.0
  publish_frequency: 2.0
  static_map: false
  rolling_window: true
  width: 6.0
  height: 6.0
  resolution: 0.05

When i run the launch file of the move_base:

<launch>

   <node pkg="move_base" type="move_base" respawn="false" name="move_base" output="screen">
    <rosparam file="$(find miniduvis)/cfg/costmap_common_params.yaml" command="load" ns="global_costmap" /> 
    <rosparam file="$(find miniduvis)/cfg/costmap_common_params.yaml" command="load" ns="local_costmap" />
    <rosparam file="$(find miniduvis)/cfg/local_costmap_params.yaml" command="load" />
    <rosparam file="$(find miniduvis)/cfg/global_costmap_params.yaml" command="load" /> 
    <rosparam file="$(find miniduvis)/cfg/base_local_planner_params.yaml" command="load" />
 </node>

</launch>

I get the following errors/ warnings and nothing is being published in cmd_vel topic:

[ WARN] [1579353283.210167580]: Timed out waiting for transform from base_link to odom to become available before running costmap, tf ...
(more)
edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
1

answered 2020-01-21 19:05:48 -0600

Namal Senarathne gravatar image

updated 2020-01-21 19:40:18 -0600

Hi, it would help immensely to if you post the launch file for hector_mapping as well.

Anyway, the short answer to resolve the WARN message is to set map as the global_frame in local_costmap.yaml. This is because hector_mapping doesn't always publish the map -> odom transform unless you configured it that way. In your case I'm guessing it only publishes map -> base_link since your robot doesn't have any odometry source. (Setting pub_map_odom_tranform would only configure hector_mapping to publish a transform to the tf tree. I'm assuming you used the option 2 in setting up Hector slam )

The first question, which topic contains the odometry that move_base will use to work? I,ve read that is tf but i've doubts.

move_base always reads the odometry from /tf. But for that to work, another source must broadcast the odometry related transforms to the TF tree. In your setting there's no odometry source and hector_mapping doesn't publish the required transform.

I have also read that you dont need to use AMCL if you are using hector_mapping to run Navigation stack, am i wrong?

You are right. To clarify, Navigation stack requires a localization source and a correct TF tree that has map -> odom -> base_link chain correctly setup. ( Or map -> base_link with global_frame set to map for both costmaps ). hector_mapping is doing SLAM and AMCL is doing localization. So either one of them could be used. The difference is for AMCL you have to provide a map through the map_server to localize against and to use for global_costmap. hector_mapping generates the map that you can use in global_costmap in addition to doing the localization.

I have noticed that the map which hector_mapping is published is not the map i have recorded with map_saver, how can i use that map?

You can't use the pre recorded map when you're using hector_mapping. hector_mapping always generates a new map everytime it is launched. It can't use existing maps. As I said earlier, you can use AMCL instead of hector_slam using the recorded map.

The footprint arg i dont really know what means, may someone explain it please? I have just copied some values i have seen in other post.

It is used to specify what it means, the footprint of the robot. Robots can be of any shape, so during configuration of move_base you have to specify what shape the robot's 2D projection is going to look like. You specify the footprint as a series of points in a polygon (with the 0,0 point being the center of the robot, using the ROS coordinate frame standard https://www.ros.org/reps/rep-0103.html#axis-orientation ) either in clockwise or counter-clockwise direction.

Hope this helps.

edit flag offensive delete link more

Comments

Interesting - I learned a lot about Nav Stack by looking at your response. Have you successfully used hector mapping as part of Nav stack to navigate in known/unknown environment?

billy gravatar imagebilly ( 2020-01-21 20:50:05 -0600 )edit

Hello Namal,

First of all thank you for your comment, i have also learnt more about Nav Stack by looking your response.

I've added the content of the launch file of hector_mapping in the main post. As you can see i think i have bad configured the odom_frame and the base_frame arg since i've set them to base_link and in the hector Slam wiki, the Option 2 set them to base_frame Anyway if i set them to base_frame i get the following error and the mapping is not working:

[ INFO] [1579869692.598166452]: lookupTransform base_frame to laser timed out. Could not transform laser scan into base_frame.

So i dont know if they have a misprint on their wiki.

Assuming that the params in hector_mapping launch file are set to base_link and changing the param base_frame in the local_costmap.yaml to map and changing the footprint param acording to the ...(more)

jjggmm gravatar imagejjggmm ( 2020-01-24 06:54:47 -0600 )edit

when i run the move_base launch file i get the following error:

[ WARN] [1579870361.339426768]: Unable to get starting pose of robot, unable to create global plan

I have set the 2D Nav Goal with Rviz and the 2D Pose Estimate.

What am i missing?

Thank you again.

jjggmm gravatar imagejjggmm ( 2020-01-24 06:58:47 -0600 )edit

Hello again,

Just noticed viewing the Pose in Rviz that the heading given by hector_mapping was in the opposite direction of the real robot heading... I had to rotate 180º and now its working.

I have a new question, does the move_base consider the dynamic obstacles in the way?

Greetings

jjggmm gravatar imagejjggmm ( 2020-01-24 09:13:16 -0600 )edit

Hi, I couldn't find the hector_mapping launch file in your main post. Anyway, it seems you got it working.

Regarding dynamic obstacles, the basic obstacle layer provided by the ObstacleCostmapPlugin (http://wiki.ros.org/costmap_2d/hydro/obstacles) can be used to update the changes in the environment. So dynamic objects can be encoded using this layer. However they are treated as static objects for that update cycle. If your costmap update rate is fast enough (say 5Hz) and robot speed is slow (say 0.5m/s) you can use this setting for many situations.

For true dynamic object encoding in costmaps, you'd have to integrate the object tracking information to the costmap as well. Social Nav Layer is one such example layer that tries to encode dynamic object more richly in a costmap.

Namal Senarathne gravatar imageNamal Senarathne ( 2020-01-25 07:54:00 -0600 )edit

Hello, i'm sorry i think i didn't save the edit of the original post. Hector_mapping launch file should be now on the original post.

I will take a look of the ObstacleCostmapPlugin. Thank you Namal,

If i could ask you another question, sometimes when i publish the 2D Nav Goal the robot start moving but does the following orders "move-stop-move-stop" very fast. And i get the following warning in the move_base:

[ WARN] [1579870361.339426768]: Unable to get starting pose of robot, unable to create global plan

It seems like it's publishing to stop the robot since it cant get the pose of robot, but it finally reach the goal, i dont really understand it.

jjggmm gravatar imagejjggmm ( 2020-01-25 08:12:28 -0600 )edit

Yes, when the planner fails to get the pose of the robot, move_base stops the robot and spits out that warning. My guess is that this move-stop-move behavior is related to the transform_tolerance parameter of costmaps. Try setting it to say 0.5 rather than your current value of 0.3.

Both global planners and local planners use this parameter to check if their output plans are relevant with respect to the current time. If the costmap takes too long to update then the plans generated based on those maps are not going to be valid/safe. If setting transform_tolerance parameter to a large value solves your problem, then ideally you should look into improving the real update rate of the costmaps used by the planners.

Namal Senarathne gravatar imageNamal Senarathne ( 2020-01-25 08:42:47 -0600 )edit

Hello again Namal, thank you for your answer.

I have set the param transform_tolerance to 0.5 and tried again to run move_base algorithm.

While testing i keep getting the following warnings:

[ WARN] [1580494333.274486301]: Costmap2DROS transform timeout. Current time: 1580494333.2743, global_pose stamp: 1580494332.7591, tolerance: 0.5000
[ WARN] [1580494333.308167650]: Could not get robot pose, cancelling reconfiguration
[ WARN] [1580494349.207849785]: Costmap2DROS transform timeout. Current time: 1580494349.2077, global_pose stamp: 1580494348.7042, tolerance: 0.5000
[ WARN] [1580494349.207964324]: Could not get robot pose, cancelling reconfiguration

I am doing the following sequence of actions , i dont know if i'm doing any mistake:

  • Robot: Launch controller and lidar nodes

  • At PC: Launch roscore, hector_mapping, move_base and Rviz to monitor everything and send goal points.

(continuing in next comment)

jjggmm gravatar imagejjggmm ( 2020-01-31 12:27:16 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2020-01-18 07:23:42 -0600

Seen: 55 times

Last updated: Jan 25