|
| 1 | +# Trajectory Cache |
| 2 | + |
| 3 | +``` |
| 4 | + * This cache does NOT support collision detection! |
| 5 | + * Plans will be put into and fetched from the cache IGNORING collision. |
| 6 | + * If your planning scene is expected to change between cache lookups, do NOT |
| 7 | + * use this cache, fetched plans are likely to result in collision then. |
| 8 | + * |
| 9 | + * To handle collisions this class will need to hash the planning scene world |
| 10 | + * msg (after zeroing out std_msgs/Header timestamps and sequences) and do an |
| 11 | + * appropriate lookup, or otherwise find a way to determine that a planning scene |
| 12 | + * is "less than" or "in range of" another (e.g. checking that every obstacle/mesh |
| 13 | + * exists within the other scene's). (very out of scope) |
| 14 | + ``` |
| 15 | + |
| 16 | +A trajectory cache based on [`warehouse_ros`](https://github.com/moveit/warehouse_ros) for the move_group planning interface that supports fuzzy lookup for `MotionPlanRequest` and `GetCartesianPath` requests and trajectories. |
| 17 | + |
| 18 | +The cache allows you to insert trajectories and fetch keyed fuzzily on the following: |
| 19 | + |
| 20 | +- Starting robot (joint) state |
| 21 | +- Planning request constraints |
| 22 | + - This includes ALL joint, position, and orientation constraints! |
| 23 | + - And also workspace parameters, and some others. |
| 24 | +- Planning request goal parameters |
| 25 | + |
| 26 | +It works generically for an arbitrary number of joints, across any number of move_groups. |
| 27 | + |
| 28 | +Furthermore, the strictness of the fuzzy lookup can be configured for start and goal conditions. |
| 29 | + |
| 30 | +## Citations |
| 31 | + |
| 32 | +If you use this package in your work, please cite it using the following: |
| 33 | + |
| 34 | +``` |
| 35 | +@software{ong_2024_11215428, |
| 36 | + author = {Ong, Brandon}, |
| 37 | + title = {A Fuzzy-Matching Trajectory Cache for MoveIt 2}, |
| 38 | + month = may, |
| 39 | + year = 2024, |
| 40 | + publisher = {GitHub}, |
| 41 | + version = {0.1.0}, |
| 42 | + doi = {10.5281/zenodo.11215428}, |
| 43 | + url = {https://doi.org/10.5281/zenodo.11215428} |
| 44 | +} |
| 45 | +``` |
| 46 | + |
| 47 | +## Example usage |
| 48 | + |
| 49 | +```cpp |
| 50 | +// Be sure to set some relevant ROS parameters: |
| 51 | +// Relevant ROS Parameters: |
| 52 | +// - `warehouse_plugin`: What database to use |
| 53 | +auto traj_cache = std::make_shared<TrajectoryCache>(node); |
| 54 | +traj_cache->init(/*db_host=*/":memory:", /*db_port=*/0, /*exact_match_precision=*/1e-6); |
| 55 | + |
| 56 | +auto fetched_trajectory = |
| 57 | + traj_cache->fetchBestMatchingTrajectory(*move_group_interface, robot_name, motion_plan_req_msg, |
| 58 | + _cache_start_match_tolerance, _cache_goal_match_tolerance, |
| 59 | + /*sort_by=*/"execution_time_s"); |
| 60 | + |
| 61 | +if (fetched_trajectory) |
| 62 | +{ |
| 63 | + // Great! We got a cache hit |
| 64 | + // Do something with the plan. |
| 65 | +} |
| 66 | +else |
| 67 | +{ |
| 68 | + // Plan... And put it for posterity! |
| 69 | + traj_cache->insertTrajectory( |
| 70 | + *interface, robot_name, std::move(plan_req_msg), std::move(res->result.trajectory), |
| 71 | + rclcpp::Duration(res->result.trajectory.joint_trajectory.points.back().time_from_start).seconds(), |
| 72 | + res->result.planning_time, /*prune_worse_trajectories=*/true); |
| 73 | +} |
| 74 | +``` |
| 75 | +
|
| 76 | +It also has the following optimizations: |
| 77 | +- Separate caches for separate move groups |
| 78 | +- The cache does "canonicalization" of the poses to be relative to the planning frame to increase the chances of cache hits. |
| 79 | +- Configurable fuzzy lookup for the keys above. |
| 80 | +- It supports "overwriting" of worse trajectories with better trajectories |
| 81 | + - If a trajectory with keys extremely close to a pre-existing cache entry is inserted with a better planned execution time, the cache can delete all "worse" trajectories. |
| 82 | + - #IsThisMachineLearning |
| 83 | + - It also prunes the database and mitigates a lot of query slow-down as the cache grows |
| 84 | +
|
| 85 | +## Working Principle |
| 86 | +
|
| 87 | +If a plan request has start, goal, and constraint conditions that are "close enough" (configurable per request) to an entry in the cache, then the cached trajectory should be suitable (as long as obstacles have not changed). |
| 88 | +
|
| 89 | +Goal fuzziness is a lot less lenient than start fuzziness by default. |
| 90 | +
|
| 91 | +Finally, the databases are sharded by move group, and the constraints are added as columns in a name agnostic fashion (they are even somewhat robust to ordering, because they're sorted!) |
| 92 | +
|
| 93 | +## Benefits |
| 94 | +
|
| 95 | +A trajectory cache helps: |
| 96 | +- Cut down on planning time (especially for known moves) |
| 97 | +- Allows for consistent predictable behavior of used together with a stochastic planner |
| 98 | + - It effectively allows you to "freeze" a move |
| 99 | +
|
| 100 | +These benefits come from the fact that the cache acts as a lookup table of plans that were already made for a given scenario and constraints, allowing the cache to be substituted for a planner call. The reuse of cached plans then allow you to get predictable execution behavior. |
| 101 | +
|
| 102 | +A user may also choose when to leverage the cache (e.g. when planning moves from a static "home" position, or repetitive/cartesian moves) to get these benefits. |
| 103 | +
|
| 104 | +Additionally, because the cache class has the ability to sort by planned execution time, over sufficient runs, the stochastic plans eventually converge to better and better plans (execution time wise). |
| 105 | +
|
| 106 | +You may build abstractions on top of the class, for example, to expose the following behaviors: |
| 107 | +- `TrainingOverwrite`: Always plan, and write to cache, deleting all worse trajectories for "matching" cache keys |
| 108 | +- `TrainingAppendOnly`: Always plan, and always add to the cache. |
| 109 | +- `ExecuteBestEffort`: Rely on cache wherever possible, but plan otherwise. |
| 110 | +- `ExecuteReadOnly`: Only execute if cache hit occurred. |
| 111 | +
|
| 112 | +You can see how such behaviors effectively model the "dev" and "deploy" phases of a robot deployment, and how they could be useful. |
| 113 | +
|
| 114 | +## Best Practices |
| 115 | +
|
| 116 | +- Since this cache does not yet support collisions, ensure the planning scene and obstacles remain static |
| 117 | +- Have looser start fuzziness, and stricter goal fuzziness |
| 118 | +- Move the robot to static known poses where possible before planning to increase the chances of a cache hit |
| 119 | +- Use the cache where repetitive, non-dynamic motion is likely to occur (e.g. known plans, short planned moves, etc.) |
| 120 | +
|
| 121 | +## WARNING: The following are unsupported / RFE |
| 122 | +
|
| 123 | +Since this is an initial release, the following features are unsupported because they were a little too difficult for the time I had to implement this. So I am leaving it to the community to help! |
| 124 | +
|
| 125 | +- **!!! This cache does NOT support collision detection!** |
| 126 | + - Trajectories will be put into and fetched from the cache IGNORING collision. |
| 127 | + - If your planning scene is expected to change between cache lookups, do NOT use this cache, fetched trajectories are likely to result in collision then. |
| 128 | + - To handle collisions this class will need to hash the planning scene world msg (after zeroing out std_msgs/Header timestamps and sequences) and do an appropriate lookup, or do more complicated checks to see if the scene world is "close enough" or is a less obstructed version of the scene in the cache entry. |
| 129 | + - !!! This cache does NOT support keying on joint velocities and efforts. |
| 130 | + - The cache only keys on joint positions. |
| 131 | +- !!! This cache does NOT support multi-DOF joints. |
| 132 | +- !!! This cache does NOT support certain constraints |
| 133 | + - Including: path, constraint regions, everything related to collision. |
| 134 | +- The fuzzy lookup can't be configured on a per-joint basis. |
| 135 | +- Alternate ordinal lookup metrics for the cache |
| 136 | + - Currently only execution time is explicitly supported as a way to compare cache entries. Ideally we should be able to inject lambdas to save custom cache DB metadata to represent and sort on custom cost functions (e.g. minimum jerk, path length, etc.). (e.g. https://github.com/moveit/moveit2/pull/2153) |
0 commit comments