carrot planner is simple, but can't make a robot move a goal?

Question

I want to ask anyone a question. I'm interested in global planner. I checked a code of a carrot_planner. carrot planner is very simple, but I think that it can't make a robot move a goal in case of being an obstacle between start position and goal position. Because the path(target_x,target_y,target_yaw) is made of following.

goal_x = goal.pose.position.x;
goal_y = goal.pose.position.y;
start_x = start.pose.position.x;
start_y = start.pose.position.y;
diff_x = goal_x - start_x;
diff_y = goal_y - start_y;
diff_yaw = angles::normalize_angle(goal_yaw-start_yaw);
target_x = goal_x;
target_y = goal_y;
target_yaw = goal_yaw;

target_x = start_x + scale * diff_x;
target_y = start_y + scale * diff_y;
target_yaw = angles::normalize_angle(start_yaw + scale * diff_yaw);

Carrot planner seems to make a plan for a robot to go straight. I mean that robot stops in front of an obstacle. What do you think of it?

---

Originally posted by Ken_in_JAPAN on ROS Answers with karma: 894 on 2014-06-09

Post score: 0

Answer 1

Yes; the carrot planner is intentionally stupid like this. I think the carrot_planner wiki describes it pretty well.

If you want obstacle avoidance you should use a more complex planner such as navfn or the sbpl_lattice_planner

---

Originally posted by ahendrix with karma: 47576 on 2014-06-09

This answer was ACCEPTED on the original site

Post score: 0

---

Original comments

Comment by Ken_in_JAPAN on 2014-06-09:
Thanks, @ahendrix! but excuse me. does sbpl_lattice_planner work normaly? I have tried to use it with a turtlebot, but it didn't work. I don't intend to do it.

Comment by ahendrix on 2014-06-09:
the sbpl_lattice_planner is still kind of experimental, and it takes some tuning to get it running properly. It works quite well for my robot.

Comment by MarkyMark2012 on 2018-02-18:
Just stumbled on this question - which is better the DWA planner or the SBPL planner for the turtlebot?

Comment by ahendrix on 2018-02-18:
DWA is probably better. I think it's the default in the turtlebot navigation package, and more users have put significantly more time into tuning and testing it. (Mathematically, it's also well-suited for the turtlebot, since turtlebot can turn in place)

Comment by MarkyMark2012 on 2018-02-20:
Cheers for getting back to me.

Comment by hc on 2018-06-18:
The navfn does not use the footprint of the robot for collision checking though, right?

Comment by ahendrix on 2018-06-18:
I am reasonably certain that navfn uses the robot's footprint (or maybe circumscribed radius) for collision checking; otherwise it wouldn't be able to plan feasible paths.

Comment by hc on 2018-06-19:
Well global_planner doesn't produce paths accounting for footprint of the robot. That part is taken care by the local planner. So I ain't too certain about navfn using footprint. It seems to just producing a path through the cells considering inflated obstacles. Inflation perhaps relates to radius.