0
$\begingroup$

Rosanswers logo

Dear people.

I just passed from groovy to Hydro. And, I found out differences in the costmaps yaml files.

I have three issues, I hope you could help me :)

1.- When I run the navigation stack, and during the trajectory of the robot to its goal I get the following error;

Extrapolation Error: Lookup would require extrapolation into the future.  Requested time 1392904133.775245246 but the latest data is at time 1392904133.766193000, when looking up transform from frame [odom] to frame [map]

[ERROR] [1392904133.785699817]: Global Frame: odom Plan Frame size 66: map

And the robot simply doesnt move at all.

2.-When the robot starts turning around to localize itself, it turns out that the update of the obstacles is quite slow and cant simply localize, and then it finds a path over the unknown area, in other words, the path is outside the map. It didnt happen in Grovvy. Is there a way to make the costmap to update faster?

3.-The Rviz shows a black cell in the origin of the map, and sometimes it shows the entire costmap inside this cell.

Any help will be appreciate it.

Thank you


Originally posted by acp on ROS Answers with karma: 556 on 2014-02-20

Post score: 0

$\endgroup$

1 Answer 1

0
$\begingroup$

Rosanswers logo

Hi,

1/ About your first issue, it looks like you have a timing problem with tf. you can run the command view_frames and check out the frames.pdf output file. This issue is quite well known so I advise you to have a look at the tf tutorials to solve this problem.

2/ I don't know if your issue is related to this but I already heard about hydro rviz being slower than the groovy version:

https://github.com/ros-visualization/rviz/issues/692

A possible solution is to recompile rviz from source with the option -DCMAKE_BUILD_TYPE=Release. You may have a similar issue with one of your other packages running slowly. Take a look at this benchmark:

http://answers.ros.org/question/71965/catkin-compiled-code-runs-3x-slower/

In my case rviz was running really slowly displaying a pointcloud2 (2fps) and it was much better after recompiling (30fps)

3/ I observed the same thing and don't know if it is normal or not. Let's wait for a feedback from someone using the navigation stack.


Originally posted by totosolat with karma: 46 on 2014-02-20

This answer was ACCEPTED on the original site

Post score: 2


Original comments

Comment by acp on 2014-02-20:
Thank you for your answer, well in order to recompile rviz from source, I may ask you some silly questions, which directory I need to go to run -DCMAKE_BUILD_TYPE=Release. I cant find any rviz package in hydro packages. Or in other words, would you be more specific about how I can recompile rviz. Thank you

Comment by totosolat on 2014-02-20:
Hi, in fact you should run catkin_make with this option. There is no silly questions but things you need to learn: please follow this tutorial. I let you go with the tutorial it will help you beginning with catkin_make.

Comment by acp on 2014-02-21:
OK, so I just run the following command ~/catkin_ws$ catkin_make -DCMAKE_BUILD_TYPE=Release, right?. I can see in rviz 30fps, but when i run rostopic hz /move_base/local_costmap/costmap it shows average rate: 0.648, it is like running around 1.54Hz, right?,

Comment by totosolat on 2014-02-21:
yes, you just have to run catkin_make -DCMAKE_BUILD_TYPE=Release. rviz running at 30 fps is not surprising when you don't display too much things. it slows down when you run heavy displays. The rate shown by rostopic hz isn't related to rviz but to the node which is publishing on the topic.

Comment by totosolat on 2014-02-21:
Since rviz isn't your main issue for now, I advise you to search which package is publishing on this topic and then try to undersand why this package isn't publishing faster. Check if you can configure this rate, and also give a look at your CPU load to see if your package is overloading the CPU...

Comment by acp on 2014-02-21:
I see, thanks, and concerning the issue of /tf. I run rosrun tf view_frames 1.- map frame (Broadcaster: /amcl Average rate: 40.126 Hz) 2.-odom frame (Broadcaster: /RosAria Average rate: 10.199 Hz). What can be wrong?

Comment by totosolat on 2014-02-21:
hum, these info are not enought to give an anwer. This is a common issue and can have different causes. For instance it can be due to a bad synchronisation between two computers if you are running ros on multiple machines. could you tell us more about your setup and post the return of view_frames?

Comment by acp on 2014-02-24:
Well, I am just using the navigation stack packages from ROS. It is a single computer that listen the odometry from the robot through RosAria. Maybe it is a synchronisation between the robot microcontroller and the computer. Here you can see the view_frames output

http://www.fit.vutbr.cz/~plascencia/frames.pdf well if you can open the link, just copy and paste into your browser.

Comment by totosolat on 2014-02-24:
Hum i'm thinking about this tutorial. So you are using a single computer directly connected to your robot (most likely with a serial connexion)? It looks like a timing synchronisation but I never had this kind of issues with my robots, so I cannot help a lot..

$\endgroup$

Your Answer

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