ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
2016-05-27 03:00:06 -0500 | commented question | Nav2d with Turtlebot failing to create map Yes, the problem was with the hokuyo description in the urdf. The hokuyo in gazebo was upside down but the base_laser_link frame was not, so the mapper didn't know how to manage that measures. |
2016-04-29 04:06:40 -0500 | commented answer | how to integrate kobuki auto docking command in roscpp or python Someone found it useful! =D |
2016-01-27 06:39:04 -0500 | received badge | ● Famous Question (source) |
2016-01-26 03:27:13 -0500 | received badge | ● Enthusiast |
2016-01-21 04:44:05 -0500 | commented answer | Nav2d with Turtlebot failing to create map Thank you so much, it was that. The problem is that the laser was upside down in the Gazebo simulation, check that if you have the same problem. Now I have other issues but I won't bother you anymore (for the moment =D). |
2016-01-21 03:51:03 -0500 | commented answer | Nav2d with Turtlebot failing to create map I don't have a problem with the name of the frames since I have the same names in the tf-tree and my robot. It seems to be a problem in the conections between the frames and I don't know how to change that configuration. I've updated the original questions with a few videos so you can see it. |
2016-01-20 05:31:15 -0500 | commented answer | Nav2d with Turtlebot failing to create map Thanks for yout time one more time. I launched the tutorial1 with Turtlebot and Gazebo and the TFs looks fine in RVIZ. The problem comes with tutorial3 and the configuration of the TFs that mapper does. Should I change the mapper.cpp to fix this? Otherwise I dont know how to change tf configuration |
2016-01-19 05:12:21 -0500 | received badge | ● Notable Question (source) |
2016-01-19 05:09:01 -0500 | commented answer | Nav2d with Turtlebot failing to create map Ok Sebastian, I've checked the tfs in RVIZ, especifically: base_laser_link, odom, base_footprint, offset and map. All work fine except for map, which jump when the robot spins. That's why the map is not created right, Isn't it? Thanks in advance. |
2016-01-19 04:14:38 -0500 | commented answer | Nav2d with Turtlebot failing to create map I've checked the transforms and the only one with a different time is the odometry one. Actually, Gazebo publish in the topic odom but no one is subscribed. I've updated the question with an image so you can see that the laser is received and the costmap is not corrupt (at least i think). |
2016-01-18 13:05:56 -0500 | received badge | ● Scholar (source) |
2016-01-18 13:05:49 -0500 | received badge | ● Supporter (source) |
2016-01-18 13:04:05 -0500 | received badge | ● Editor (source) |
2016-01-18 13:03:28 -0500 | commented answer | Nav2d with Turtlebot failing to create map Im working in Gazebo for the moment. cmd_vel go into Gazebo since the Operator is able to move the robot. What should I look for in the tf-tree? I've checked it before to see if "laser_frame", "robot_frame" and "odom_frame" were OK, and they seem so. Tf-tree in the question. Thanks for your answer. |
2016-01-18 12:53:50 -0500 | received badge | ● Popular Question (source) |
2016-01-18 04:46:17 -0500 | asked a question | Nav2d with Turtlebot failing to create map Hello everyone! Im trying to use nav2d package with turtlebot and hokuyo laser to map an unknown room. I think I've all well conected, as you can see on my rqt_graph: I can use the /StartMapping service but it seems to fail at this point. These are the /map and the /Operator/local_map/costmap in RVIZ. Map: Costmap: Obviously, Exploration doesn't work well with these maps. My tf-tree:https://drive.google.com/open?id=0B8A... The laser-scan and costmaps seem OK: Some videos of the problem: This is a video of the first Tutorial1 (Nav2d). I'm showing you odom and the base_footprint frames. As you can see, all the conections between the frames seem OK. https://drive.google.com/open?id=0B8A... The next two videos are from Tutorial3 (Nav2d). The point of view is from map in the RVIZ, as you can see this frame is upside down, I don't know why. It seems to be an issue at this point, since odom and offset frame make aparently random jumps. https://drive.google.com/open?id=0B8A... The last one is from the perspective of base_link of the robot. I show you both, the map and the costmap. The map frame seems to maintain the reference with the map. https://drive.google.com/open?id=0B8A... I hope these videos help you to understand the problem. This is my launch file:
(more) |