mlphilli's profile - activity

Are the motion primitives themselves not smooth or just the resulting path which is composed of the motions?

In terms of motion primitive design, you may consider reading this: M. Pivtoraiko and A. Kelly, "Generating near minimal spanning control sets for constrained motion planning in discrete state spaces"

I'd like to look into the error you're getting when replanning often....are you using ARA* or AD*?

This warning is related to your problem (I'll probably get rid of the warning in the future). The sipp and interval environments assume that waiting is allowed as a prefix to every motion primitive therefore any "wait" action specified in the motion primitive file is ignored because the planner is going to use waits wherever it needs to.

While I can't say for sure without looking at it, the likely reason (especially if your epsilon is 1, optimal) for the behavior you are seeing is that it is at least as fast if not faster to get to the goal, by waiting for the obstacles to "disappear". When the dynamic obstacle trajectories end, it is as if they disappear. If you want to make sure the planner "deals with" the dynamic obstacles instead of waiting until they disappear you have to make sure the trajectories are long enough for it to be cheaper for the robot to do what you expect than waiting for trajectories to end.

Hope that helps!

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.