ROS Resources: Documentation | Support | Discussion Forum | Index | Service Status | ros @ Robotics Stack Exchange |
2013-05-29 09:39:48 -0500 | commented answer | Navigating with a differential drive rectangular robot We think that the "forward_point" parameter is probably the best improvement for us because it keeps our robot's heading more consistent. |
2013-05-29 09:38:13 -0500 | commented answer | Navigating with a differential drive rectangular robot Our problem has since been resolved (mostly...). We think that our robot was too long and rectangular to use the trajectory_planner, however we were able to fix some bugs that were preventing us from using the DWA planner which works much better. |
2013-05-29 09:34:51 -0500 | received badge | ● Famous Question (source) |
2013-05-29 09:33:35 -0500 | received badge | ● Good Question (source) |
2013-05-27 15:39:33 -0500 | received badge | ● Favorite Question (source) |
2013-05-25 09:27:15 -0500 | received badge | ● Notable Question (source) |
2013-05-25 04:16:15 -0500 | received badge | ● Nice Question (source) |
2013-05-25 03:18:33 -0500 | received badge | ● Popular Question (source) |
2013-05-24 23:11:59 -0500 | received badge | ● Student (source) |
2013-05-24 10:56:23 -0500 | asked a question | Navigating with a differential drive rectangular robot Currently we are using the Navfn global planner with the Trajectory_Rollout local planner on our differential-drive robot that is approximately 1 meter by 0.6 meters (with the center of the differential-drive being approximately 0.35 meters from the back of the robot). You can see a picture of our robot here: So far we have had limited success with our path planning. At the moment we believe that our biggest problem is that the robot will attempt to keep its center point (the center of the wheelbase) on the global path at all times, and if it moves slightly off the path it will end up spinning (usually a multiple of 360 degrees) until it merges back onto the path where it left off with the correct heading. (We have already tried all suggestions from this thread those linked on the same page) We have been reading old forum messages and we think that our problem may be that the Navfn planner does not give pose requirements to local goals, meaning that when we reach curves on our path the robot will come in with the wrong heading and start its spinning problem. We wanted to use the pose_follower based on dialogue from this archive but it gave no messages and didn’t move when we ran it. We also tried the sbpl_lattice_planner to no avail. We are wondering whether or not a global/local planner has been developed that works well with rectangular shaped robots. From our experience and what we’ve read from other users with similarly shaped differential drive robots, tuning the parameters on our current planners is not enough to get a reliable solution. We looked at the development on the PR2 for cart pushing, but we were unsure if we should attempt to make our robot "look" like a smaller square robot pushing a similarly shaped square cart. Your feedback is greatly appreciated. Here are our parameters that we're currently using: |
2013-05-23 21:52:08 -0500 | received badge | ● Great Answer (source) |
2013-05-23 21:52:08 -0500 | received badge | ● Guru (source) |
2013-05-23 05:57:42 -0500 | received badge | ● Good Answer (source) |
2013-05-23 05:57:42 -0500 | received badge | ● Enlightened (source) |
2013-05-23 05:27:36 -0500 | received badge | ● Supporter (source) |
2013-05-23 05:26:59 -0500 | received badge | ● Nice Answer (source) |
2013-05-23 05:26:24 -0500 | received badge | ● Teacher (source) |
2013-05-23 05:25:42 -0500 | answered a question | gmapping missing spots For the SICK LMS lidar you can set the "use_rep_117_" global parameter to "false" to force it to report readings in legacy format instead of using Inf/NaN. It seems that the gmapping package rejects Inf/NaN values. Use this information in combination with the maxRange and maxUrange suggestion that Ben has offered. |