0
$\begingroup$

Rosanswers logo

Hi,

I am having a problem with basic nav_stack that I am hoping someone can provide basic guidance. I am sorry if it is a silly question, but I have been stuck on this for a while now.

I have started following the example in the tutorial in "navigation_stage" and changing the parameters to suit my sensors (I am trying to replace what is provided by stage with my own sensors) (I also read the navigation tunning page)

My problem is that although my TF, sensors topics, etc seems to be correct, both slam_gmapping and move_base_node only receive data from my laser scanner during startup and are unable to receive further data later (the blue "inflated_obstacles" is never updated in RVIZ neither is the red obstacles). Move_base often goes into "recovery mode" and starts spinning on the spot indefinitely. The main slam_gmapping map also does not update.

System: ROS fuerte - Ubuntu 12.04 Hokuyo urg-04lx-ug01 - hokuyo node

My configuration is: tf:

image description http://imageshack.us/photo/my-images/812/ttkg.jpg/

RXgraph:

image description http://imageshack.us/photo/my-images/844/d2z.png/

move_base_node during startup:

Blockquote

[ INFO] [1371438183.853530142]: Subscribed to Topics: base_scan [ INFO] [1371438183.862700484]: Requesting the map...

[ INFO] [1371438183.863425766]: Still waiting on map... -maxUrange 16 -maxUrange 5.59 -sigma 0.05 -kernelSize 1 -lstep 0.05 -lobsGain 3 -astep 0.05 -srr 0.01 -srt 0.02 -str 0.01 -stt 0.02 -linearUpdate 0.5 -angularUpdate 0.436 -resampleThreshold 0.5 -xmin -50 -xmax 50 -ymin -50 -ymax 50 -delta 0.05 -particles 80 [ INFO] [1371438184.212892567]: Initialization complete update frame 0 update ld=0 ad=0 Laser Pose= 0 0 0 m_count 0 Registering First Scan [ INFO] [1371438184.875935661]: Still waiting on map...

[ WARN] [1371438185.866335009]: You have set map parameters, but also requested to use the static map. Your parameters will be overwritten by those given by the map server [ INFO] [1371438185.866382623]: Received a 1984 X 1984 map at 0.050000 m/pix [ WARN] [1371438186.676822580]: The /scan observation buffer has not been updated for 0.79 seconds, and it should be updated every 0.10 seconds. [ INFO] [1371438186.750536948]: MAP SIZE: 1984, 1984 [ INFO] [1371438186.754008079]: Subscribed to Topics: base_scan [ INFO] [1371438186.907250975]: Sim period is set to 0.10

Blockquote

My config for the costmap is:

Blockquote

observation_sources: base_scan

base_scan: { sensor_frame: /base_laser_link, topic: /scan, data_type: LaserScan, expected_update_rate: 0.1, observation_persistence: 0.0, marking: true, clearing: true, max_obstacle_height: 0.4, min_obstacle_height: 0.08}

Blockquote

I wrote my own EKF based on MRPT EKF.(this might be cause of the problem, but I do not see how it affects it)

I should maybe mention that the packages seem to operate well since in simulation everything runs smoothly. (when using stage, everything works) I have checked the DEBUG messages for the move_base and slam_gmapping and there is nothing that stands out as being completely wrong. (just the standard message filter)

Hector mapping is working OK using the same transforms. However, gmapping or move_base_node are not.

Thank you for your time and help.


Originally posted by pmolina on ROS Answers with karma: 108 on 2013-06-16

Post score: 0

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

I figured it out

Basically, the cost_map settings do not change every time the move_base system is launched.

I will change the name of the topic of the laser in the cost_map.xml file, but it would not be updated in param_server for some reason. Hence, once I launched move_base it will still use the old topic name (this is how I found out...)

If I restarted ROS core (that restarts param_server), then it will start working.

Is this expected behaviour? do I have to close ROS Core every time?

Thanks


Originally posted by pmolina with karma: 108 on 2013-06-17

This answer was ACCEPTED on the original site

Post score: 0

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.