MRSL Motion Primitive Library
1.2
A motion primitive library for generating trajectory for mobile robots
|
Motion Primitive Library is a search-based planner to compute dynamically feasible trajectories for a quadrotor flying in an obstacle-cluttered environment. Our approach searches for smooth, minimum-time trajectories by exploring the map using a set of short-duration motion primitives. The primitives are generated by solving an optimal control problem and induce a finite lattice discretization on the state space which can be explored using a graph-search algorithm. The proposed approach is able to generate resolution-complete (i.e., optimal in the discretized space), safe, dynamically feasibility trajectories efficiently by exploiting the explicit solution of a Linear Quadratic Minimum Time problem. It does not assume a hovering initial condition and, hence, is suitable for fast online re-planning while the robot is moving.
More details about the algorithm can be found in following publications:
ellipsoid_planner
to mpl_ros
Eigen
: apt install libeigen3-devYAML-CPP
: apt install libyaml-cpp-devOpenCV
: apt install libopencv-devor simply run following commands:
#### A) Simple cmake
#### B) Using Catkin (not recognizable by catkin_make)
Run following command in the build
folder for testing the executables:
If everything works, you should see the results as:
To link this lib properly, add following in the CMakeLists.txt
To run the planner, three components are required to be set properly:
We use theclass Waypoint
for the start and goal. A Waypoint
contains coordinates of position, velocity, etc and the flag use_xxx
to indicate the control input. An example for 2D planning is given as:
The flag use_xxx
indicates the planner to plan in different control space. For example, the above example code sets the control in ACC
space. Eight options are provided by setting following flags:
~ | VEL | ACC | JRK | SNP | VEL&YAW | ACC&YAW | JRK&YAW | SNP&YAW |
---|---|---|---|---|---|---|---|---|
use_pos: | true | true | true | true | true | true | true | true |
use_vel: | false | true | true | true | false | true | true | true |
use_acc: | false | false | true | true | false | false | true | true |
use_jrk: | false | false | false | true | false | false | false | true |
use_yaw: | false | false | false | false | true | true | true | true |
In equal, one can also set the attribute control
of Waypoint
for the same purpose:
~ | VEL | ACC | JRK | SNP | VEL&YAW | ACC&YAW | JRK&YAW | SNP&YAW |
---|---|---|---|---|---|---|---|---|
control: | Control::VEL | Control::ACC | Control::JRK | Control::SNP | Control::VELxYAW | Control::ACCxYAW | Control::JRKxYAW | Control::SNPxYAW |
Any planner needs a collision checking function, there are several utils in this package to checking collision for obstacles in different representations. In the most common environment where obstacles are represented as voxels, we use class MapUtil
which is a template class that adapts to 2D (OccMapUtil
) and 3D (VoxelMapUtil
). An example for initializing a 2D collision checking OccMapUtil
is given as:
Here origin
, dim
, data
and resolution
are user input.
Our planner takes control input to generate primitives. User need to specify it before start planning. An example for the control input U
for 2D planning is given as following, in this case, U
simply include 9 elements:
After setting up above 3 required components, a plan thread can be launched as:
After compiling by cmake
, run following command for test a 2D planning in a given map:
You should see following messages if it works properly:
The output image is saved in the current folder:
(blue dots show the expended states, blue and cyan circles indicate start and goal).
Run following command for test a 2D planning, it first finds a trajector in low dimensional space (acceleration-driven), then it uses the planned trajectory to refine for a trajectory in high dimensional space (jerk-driven):
In the following output image, the black curve is the prior trajectory:
In some cases, the robot needs to move forward within the FOV of the camera or range sensor such that the yaw needs to be considered when planning. MapPlanner
handles the yaw constraint properly. Following image shows the output of running:
In practical case, the robot wants to stay away from obstacles even though the nominal trajectory is collision free. To add a soft constraint based on the distance towards obstacles, one technique is to use the artificial potential field (APF). In this examplem, we show how to perturb a nominal trajectory based on the search-based method with APFs:
In addition, to do the perturbation iteratively, run the other node:
In a more comprehensive case, when the robot has limited FOV and sensing range, plan the trajectory that considers safety and yaw constraint:
This example illustrate the mpl_traj_solver
which is a smoothing tool to derive a smoother trajectory. An example of generating trajectory from a given path, without obstacles:
Here we generate three different trajectories using the same path and time allocation: the red one is minimum velocity trajectory, the green one is the minimum acceleration trajectory and the blue one is the minimum jerk trajectory.
For API, please refer to Doxygen.
The interface with ROS for visualization and implementation can be found in mpl_ros
.