0
$\begingroup$

Rosanswers logo

Hello all,

I have a problem with my robot setup which I cannot resolve, even after reading all relevant posts on here. I really would appreciate your help.

###Problem Description The system starts up not generating any errors (see https://dl.dropboxusercontent.com/u/10986309/2013-05-23_ros.answers/start_up_log.txt), producing an accurate map, and localization working well, too. As soon as I select a goal in rviz, move_base reproducibly throws the following errors:

[  ...]
[ERROR] [1369321339.784772926]: Extrapolation Error: Unable to lookup transform, cache is empty, when looking up transform from frame [/odom] to frame [/map]
[ERROR] [1369321339.785409391]: Global Frame: /odom Plan Frame size 107: /map
[ WARN] [1369321339.785726634]: Could not transform the global plan to the frame of the controller
[ERROR] [1369321340.434425166]: Extrapolation Error: Unable to lookup transform, cache is empty, when looking up transform from frame [/odom] to frame [/map]
[ERROR] [1369321340.434493357]: Global Frame: /odom Plan Frame size 107: /map
[ WARN] [1369321340.434528719]: Could not transform the global plan to the frame of the controller
[  ...]

However, if I make the following change in the local_costmap_params.yaml file:

local_costmap: global_frame: /odom

to

local_costmap: global_frame: /map

I don't get any errors and move_base generates a plan to the goal, which is also displayed in rviz. Unfortunately, the generated cmd_vel commands are very shaky, oscillate and weird navigation behaviour is the result.

###My Setup

  • Robot: Custom robot with chain drive, i.e. non-holonomic. I have written a base_controller node for it which sends drive commands to the motors and uses the encoder information to calculate odometry and publish as tf+nav_msg (as described http:// www.ros.org/wiki/navigation/Tutorials/RobotSetup/Odom). I have also created a *.urdf file and use robot_state_publisher to publish the tf's for the model.
  • Sensors: Hokuyo UTM-30LX laser scanner
  • Nodes: max_driver (custom base_controller), hector_mapping, move_base, hokuyo_node
  • hector_mapping config:

[hector_config.launch] https:// dl.dropboxusercontent.com/u/10986309/2013-05-23_ros.answers/hector_config.launch

  • move_base config:

[move_base_config.launch] https:// dl.dropboxusercontent.com/u/10986309/2013-05-23_ros.answers/move_base_config.launch

[base_local_planner_params.yaml] https:// dl.dropboxusercontent.com/u/10986309/2013-05-23_ros.answers/base_local_planner_params.yaml

[costmap_common_params.yaml] https:// dl.dropboxusercontent.com/u/10986309/2013-05-23_ros.answers/costmap_common_params.yaml

[global_costmap_params.yaml] https:// dl.dropboxusercontent.com/u/10986309/2013-05-23_ros.answers/global_costmap_params.yaml

[local_costmap_params.yaml] https://dl.dropboxusercontent.com/u/10986309/2013-05-23_ros.answers/local_costmap_params.yaml

  • Remote nodes: The hokuyo_node and the base_controller node run on an embedded PC, which is connected via ethernet to a powerful laptop running the remaining nodes. The time of both machines is synced via crony.
  • SW-Version: Ubuntu 12.04 + ROS Groovy, everything up to date

###Debug Info

  • tf tree: [link] (https:// dl.dropboxusercontent.com/u/10986309/2013-05-23_ros.answers/frames.pdf)
  • tf_monitor output:
ros@Base:~$ rosrun tf tf_monitor
RESULTS: for all Frames

Frames:
Frame: /base_frame published by /max_driver Average Delay: -0.00377412 Max Delay: 0
Frame: /base_laser published by /robot_state_publisher Average Delay: -0.476582 Max Delay: 0
Frame: /base_laser_cap published by /robot_state_publisher Average Delay: -0.476592 Max Delay: 0
Frame: /base_laser_mount_box published by /robot_state_publisher Average Delay: -0.476591 Max Delay: 0
Frame: /base_laser_mount_cylinder published by /robot_state_publisher Average Delay: -0.47659 Max Delay: 0
Frame: /base_turret published by /robot_state_publisher Average Delay: -0.476589 Max Delay: 0
Frame: /box_battery published by /robot_state_publisher Average Delay: -0.476588 Max Delay: 0
Frame: /box_slam published by /robot_state_publisher Average Delay: -0.476587 Max Delay: 0
Frame: /flipper_left_front published by /robot_state_publisher Average Delay: -0.476586 Max Delay: 0
Frame: /flipper_left_rear published by /robot_state_publisher Average Delay: -0.476585 Max Delay: 0
Frame: /flipper_right_front published by /robot_state_publisher Average Delay: -0.476584 Max Delay: 0
Frame: /flipper_right_rear published by /robot_state_publisher Average Delay: -0.476583 Max Delay: 0
Frame: /odom published by /hector_mapping Average Delay: 0.0199384 Max Delay: 0.0232629
Frame: /scanmatcher_frame published by /hector_mapping Average Delay: 0.0199549 Max Delay: 0.0232747

All Broadcasters:
Node: /hector_mapping 80.3703 Hz, Average Delay: 0.0199466 Max Delay: 0.0232747
Node: /max_driver 60.1367 Hz, Average Delay: -0.00377412 Max Delay: 0
Node: /robot_state_publisher 50.0022 Hz, Average Delay: -0.476587 Max Delay: 0
  • rosnode list:
ros@Base:~$ rosnode list
/hector_geotiff_node
/hector_mapping
/hector_trajectory_server
/joint_state_publisher
/laser_scan_sensor
/max_driver
/move_base
/robot_state_publisher
/rosout
/rqt_gui
/rviz

Please let me know if there is any information missing that might help to resolve this issue.

P.S.: Sorry for the broken links - my karma was insufficient to post links. Just remove the space after http:// and it will work again.


Update 1

I am not sure whether the odom frame behaves the way it should when watching it while driving. This is what I see:

  • The values of the odom nav_msg (/odom/pose/position/x,y and /odom/pose/orientation/z) look good
  • The odom frame in rviz doesn't follow base_frame, nor does it stay stationary locked to the map frame. It just moves in tiny fractions, sort of oscillates, and rotates around the origin of base_frame. (I could make a video if that would help.)

Is this the expected behaviour?

Thanks


Update 2

Still unable to resolve this issue.

  • Anyone out there who has seen this error message before?
  • Anyone using hector_mapping and move_base together who could look over my setup?
  • Any move_base experts out there who can tell me how I can debug and check out what's going on under the hood of move_base?

Cheers


Originally posted by Huibuh on ROS Answers with karma: 399 on 2013-05-23

Post score: 4


Original comments

Comment by Gazer on 2013-06-18:
it would be great if you could provide solution to your problem, because I believe most ppl like me is struggling to get the navigation stack to work. Thank you verymuch!

Comment by Achim on 2013-08-07:
I have the same problem. I looked at the code, the lookup fails in transformGlobalPlan, https://github.com/ros-planning/navigation/blob/groovy/base_local_planner/src/goal_functions.cpp Either this is too strict about the timestamps or it has a bug which only surfaces in special cases.

Comment by Achim on 2013-08-12:
I tried move_base with gmapping last week and got a similar issue... the robot moved for a few centimeters sometimes, but stopped with the same messages. Comparing the TFs, I get 40Hz from hector_slam and 50Hz from gmapping. So it seams the local planner is too strict with timestamps.

Comment by Huibuh on 2013-08-12:
Hello Achim, I just saw your two recent posts. What are you suggesting to fix the problem? Increase the frequency of hector_slam? I still haven´t found a solution to make it work...

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

That's a very exhaustive report - certainly very helpful for finding the cause for your troubles. That being said, the cause of the problem isn't immediately obvious to me, as things look fine from looking over them (at least from a published tf/hector_mapping POV). I assume the /odom frame moves around in rviz as expected? First guess would've been some time sync problem between computers, but looking at your exhaustive tf debugging output, that doesn't seem to be the case. If there's no other troubles regarding the state estimation (robot pose, map etc all look fine) my guess is that the culprit is the setup of move_base (which hopefully someone else can look at).


Originally posted by Stefan Kohlbrecher with karma: 24361 on 2013-05-23

This answer was ACCEPTED on the original site

Post score: 0


Original comments

Comment by Huibuh on 2013-05-23:
Thank you for taking a look at this Stefan. Please see my updated post above regarding your odom frame question.

Comment by Stefan Kohlbrecher on 2013-05-24:
That sounds like correct odom frame behavior. What you could try is setting the fixed frame to odom and see if LIDAR data with decay time drifts slowly when the robot is moving as described here in comments: http://answers.ros.org/question/9983/why-the-slam-have-more-than-one-maps-in-rviz/

$\endgroup$

Your Answer

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