Revision history [back]

Hi Sagnik, Your first two questions are getting at how move_base and sbpl_lattice_planner interact. The sbpl_lattice_planner is just class that adheres to the global planner API so that move_base can use it. You can use the sbpl_lattice_planner by itself (without move_base) by calling the initialize and makePlan functions in order to just get back the (x,y,theta) path.

The move_base package does exactly this to get a path, and then follows the path (moving the robot) using some local planner. So if you don't want the robot to move, just don't use move_base, just use sbpl_lattice_planner by itself.

When you observe the planner re-plan during execution it is actually move_base calling the planner again for a new path. This can happen for a few reasons such as the robot getting too far off the path, or an obstacle being detected on the path currently being followed (so the path is invalid).

In terms of motion primitives for an Ackerman steering robot, you should be able to use one of the unicycle files. These motions can be used to create smooth arcs that a steering type robot would follow. This may not be good enough though if you need to model that in a car like robot you can't change the steering angle instantaneosly. If this is important, you need to plan in an (x,y,theta,phi) state space. In this case you may be able to modify the sbpl_cart_planner for your purposes.