Ask Your Question
0

Unable to start costmaps in navigation stack

asked 2018-02-08 05:45:40 -0600

nikfio gravatar image

updated 2018-02-08 05:59:55 -0600

Hello everyone. I am now working with the Create 2 robot - Roomba 600 platform - with the driver from AutonomyLab and a Hokuyo LRF. Everything is running perfect, but when I try to enable the navigation stack, the terminal does not log activation of obstacle layer and inflation layer, meaning the costmaps are not enabled on Rviz.

Meanwhile in Gazebo everithing works smoothly with the same parameters settings, so I have two computers connected in the same wireless, this is the procedure I take*

  1. launch create and hokuyo driver with scan:=base_scan frame_id:="same name written in urdf file"
  2. rosrun gmapping slam_gmapping scan:=base_scan _linearUpdate:=0 _angularUpdate:=0 - starts LiveSlam()
  3. start move_base node with all the parameters of global and local planner, global and local costmap

Communications is realized with a local VPN, port 1194 over UDP.

I tried many possible solutions but no one seems to work in a stable way, so I would like to ask for your help here. One thing that made me think is about the view_frames output that is very different from gazebo case, which uses use_sim_time = true, so a possible cause I was thinking is about time synchronization.

Il'post here some important screenshot and config settings and outputs:

In common_costmap_params.yaml:

 #Configuration for the sensors that the costmap will use to update a map
observation_sources: base_scan
base_scan: {sensor_frame: hokuyo_link, data_type: LaserScan, topic: /base_scan, expected_update_rate: 0.4,observation_persistence: 0.0, marking: true, clearing: true, max_obstacle_height: 0.4, min_obstacle_height: 0.08}

From navigation stack logging:

[ WARN] [1518088865.446447100]: Timed out waiting for transform from base_footprint to map to become available before running costmap, tf error: Lookup would require extrapolation into the past.  Requested time 1518088839.115352594 but the earliest data is at time 1518088855.527055015, when looking up transform from frame [base_footprint] to frame [map]. canTransform returned after 0.100919 timeout was 0.1.

From view frames:

map->odom->base_footprint->base_link-> to everyone published by robot_state_publisher related to urdf tree

It's showing 20 Hz on slam_gmapping, robot driver and LRF sensor with also:

Most recent transform: 1518088979.565 ( 26.377 sec old)
Buffer length: 4.900 sec

The tf parts published by robot_state_publisher are posting: average rate = 10000 Hz

And in these components of the frames at "most recent transform" I have:

Most recent transform: 0.000 ( 1518089005.943 sec old)
Buffer length: 0.000 sec

The important effect of all of this is that move_base_node ends up to not be a subscriber of /base_scan, so the obstacle plugins cannot enable.

I think wrote the most important effects for me, but if you suggest to post something else i will be happy to. I would be very grateful to the ones who want to give suggestions or ideas.

edit retag flag offensive close merge delete

Comments

1

Two things to check:

  1. make sure all hosts can communicate with each other (ROS_IP, ROS_MASTER_URI, etc)
  2. make sure time is synchronised between the hosts

For more info on both, see wiki/ROS/NetworkSetup.

gvdhoorn gravatar imagegvdhoorn ( 2018-02-08 05:48:18 -0600 )edit

Communications is realized with a local VPN, port 1194 over UDP.

Can you clarify why you decided to do this?

gvdhoorn gravatar imagegvdhoorn ( 2018-02-08 05:51:12 -0600 )edit

thank you @gvdhoorn for your reply. Communication is stable through the tun0 interface, I can ping each other and run teleop_twist without any problem. About synchronization I didn't take any real precautions yet, I tried today to config ntp but not successfully, do you have any hints?

nikfio gravatar imagenikfio ( 2018-02-08 05:58:03 -0600 )edit

Regarding vpn configuration, I tried any solution but that one seemed to be the only one really working. At first, I preferred TCP but didn7t work out.

nikfio gravatar imagenikfio ( 2018-02-08 06:03:55 -0600 )edit
1

About synchronization I didn't take any real precautions yet, I tried today to config ntp but not successfully, do you have any hints?

the linked wiki article has a section on time synchronisation.

gvdhoorn gravatar imagegvdhoorn ( 2018-02-08 06:07:05 -0600 )edit

I'm not asking about the UDP usage for the VPN, but the use of the VPN in general.

gvdhoorn gravatar imagegvdhoorn ( 2018-02-08 06:07:34 -0600 )edit

Communication is stable through the tun0 interface, I can ping each other and run teleop_twist without any problem

I would still recommend to make sure that pub-sub works in both directions (using rostopic pub .. and rostopic echo ..) as iirc teleop_twist is unidirectional.

gvdhoorn gravatar imagegvdhoorn ( 2018-02-08 06:08:26 -0600 )edit

Essentially, because by simply setting ROS_IP and ROS_MASTER_URI was not working, I guess it's due to having desktop pc connected to LAN, and laptop to one of the two wireless networks that can change. Echoing and puclishing are working anytime.

nikfio gravatar imagenikfio ( 2018-02-08 06:36:48 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted
1

answered 2018-02-08 06:38:46 -0600

gvdhoorn gravatar image

updated 2018-02-08 08:21:23 -0600

Ok, good. That's out of the way then.

Time synced as well? I find the 26.377 sec old a bit much for a TF frame that is published at x Hz per second.


Edit:

SOLVED! it was because of synchronization, my laziness made me avoid section 5 of that article before. The first run of ntpdate was showing an offset of 26 s , after syncing it got to 0.0000008. And now everything is working perfectly, so I can start collect navigation data for my databases. Thanks

Know that runnint ntpdate a single time will not keep your system synchronised. Due to having different clocks, they will probably start to diverge more and more over time.

edit flag offensive delete link more

Comments

SOLVED! it was because of synchronization, my laziness made me avoid section 5 of that article before. The first run of ntpdate was showing an offset of 26 s , after syncing it got to 0.0000008. And now everything is working perfectly, so I can start collect navigation data for my databases. Thanks

nikfio gravatar imagenikfio ( 2018-02-08 06:43:06 -0600 )edit

SOLVED!! Guys, if you a have a strange result from

rosrun tf view_frames

The first thing to make sure it's to check synchronization and adjust it anyway to be safe. So, instructions are at the bottom of this page - Section 5 - http://wiki.ros.org/ROS/NetworkSetup .

nikfio gravatar imagenikfio ( 2018-02-08 06:47:17 -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: 2018-02-08 05:43:46 -0600

Seen: 289 times

Last updated: Feb 08 '18