Avoid redundant TF lookups in getShapeTransformCache - #3803
Conversation
getShapeTransformCache rebuilds on every octomap/sensor update and walks the TF tree twice per shape-bearing frame: canTransform first (a check), then lookupTransform (the actual compose). lookupTransform already composes the transform and throws tf2::TransformException if it's unavailable, which the function's existing try/catch already handles, so the canTransform check duplicates work lookupTransform does anyway. Drop it and call lookupTransform directly inside the existing try/catch. Cache contents are unchanged: lookupTransform returns the same transform whether or not canTransform was called first. One real behavioral difference worth being explicit about: canTransform(..., shape_transform_cache_lookup_wait_time_) also waits up to that duration (a ROS parameter, "<robot_description>_planning.shape_transform_cache_lookup_wait_time", defaulting to 0.05s) for a not-yet-available transform. Dropping it removes that wait. When a transform is available at target_time (the normal case), behavior is identical. If one is momentarily late, the current code waits up to the configured duration; this throws immediately, and the try/catch returns false for that update (the next sensor update tries again). The wait-time parameter itself becomes a no-op, since this was its only reader.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan includes up to 3 reviews per rolling hour; 0 remain after this review. 📝 WalkthroughWalkthroughChangesThe planning scene monitor now resolves shape transforms per frame. It first performs a direct Shape transform cache
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: 🔵 Low · up to The change removes the configured wait for temporarily unavailable transforms and changes failures from skipping one affected frame to stopping the remaining cache work for that update. This is mergeable with owner awareness because transient TF delays could leave less of the cache populated during a pass. Sequence Diagram(s)sequenceDiagram
participant getShapeTransformCache
participant tf2BufferCore
participant tf2Buffer
participant shapeTransformCache
getShapeTransformCache->>tf2BufferCore: Request transform at timestamp
tf2BufferCore-->>getShapeTransformCache: Return transform or failure
getShapeTransformCache->>tf2Buffer: Retry with configured wait duration
tf2Buffer-->>getShapeTransformCache: Return transform or failure
getShapeTransformCache->>shapeTransformCache: Add entry when transform is available
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Description
getShapeTransformCache()currently callscanTransform()before eachlookupTransform(), causing an extra TF-tree traversal when the transform is already available.This change performs a single direct lookup on the common path. If it is not immediately available, it retries with
shape_transform_cache_lookup_wait_time_. A missing transform skips only that frame, so the rest of the cache is still populated.Results
Real
tf2::BufferCore, mean cache-build time:Testing
Added coverage for a transform that arrives during the configured wait and for continuing after one frame is unavailable.
Built
moveit_ros_planningand ranplanning_scene_monitor_testinmoveit/moveit2:humble-ci: 4/4 gtests passed; colcon reported 3 tests, 0 errors, 0 failures, 0 skipped.Checklist