Limitations and Known Issues
The lattice_planner was originally designed to plan social navigation paths (see human_aware_navigation repository) in home environments. Very big maps, for example maps that cover entire company buildings over multiple floors, cannot be handled by the planner. Every planning cycle starts with the calculation of the heuristic for planning by doing a 2D Dijkstra expansion over the entire map to find the shortest possible path from every cell in the map to the goal. If the map is very big, this expansion can take up the entire time allocated for planning. Therefore, there is no time left to expand the search tree and a path from the start to the goal cannot be found, even if the distance between them is very small. If that happens, the lattice_planner will report: "no path found within 0 cycles".
Time dependent planning tends to be computationally expensive, especially for robots with differential drive constraints due to the high dimension of the planning space (x,y,theta,t). Furthermore, we represent dynamic constraints (maximum accelerations), which results in a 6D planning space which also includes the robot velocities: (x,y,theta,v,omega,t) Therefore, the lattice_planner has some limitations to keep the planning time acceptable.
It is important to keep the size of the discretized planning space reasonable. In practice, this means that the planning look-ahead should not be too large. Usually, it can cope with 10-20 prediction steps (time_steps_lookahead param). The look-ahead time depends on the specified time resolution (time_resolution param). A good value for the resolution is 0.5 seconds. Significantly smaller resolutions cause a very large planning space. Furthermore, since one planning cycle corresponds to the specified time resolution, the planner will need many planning cycles to make progress towards the goal. The specified robot accelerations (acceleration_x and acceleration_phi params) determine how many time steps are required to reach the specified robot velocities (min_vel_x, max_vel_x, min_vel_phi and max_vel_phi params). The accelerations thus determine how many discrete velocities the planner can represent. Planning can be problematic if the acceleration (or the time resolution) is very small or if the maximum velocity is very large, because the planner has to consider a large number of possible discrete velocities. Ideally, the accelerations and velocities should be specified in a way that it takes 1 or 2 time steps to go from minimum to maximum velocity (velocity_(i+1) = velocity_i + acceleration * time_resolution).
To simplify the planning procedure, set the planning params easy_deceleration, easy_turn_at_start or easy_turn_at_goal to true. The flags violate the solution optimality but accelerate the search procedure.
The planner might produce incomplete paths because it is unable to expand the goal state before the planning time expires.
The published, incomplete path is the path to the best state found so far. Therefore, the robot is likely to proceed towards the goal and should eventually find a complete path. However, it is possible that the robot gets stuck. It can get into situations where it can never find a complete path before the planning time runs out. This will result in the robot moving around "randomly" and never making progress towards the goal. If that happens to you in a lot of situations, consider to lower the planning frequency and to enlarge the planning timeout to give the planner more time to find a path. A very weak PC might also cause this problem.