Repository navigation
UrdfManager: URDF self-masking and joint tf - #4612
jeff-hykin wants to merge 6 commits into
Conversation
…joints on tf, and cuts the robot out of point clouds (self-masking); replaces RoboPlanPointCloudSelfFilter (the xArm grasp blueprint uses it with its joint tf off), serves the URDF and its meshes on request (MeshFile), and logs a self-filter summary
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
go2 replay realtime (arm64)
Details
| Benchmark suite | Current: 177b741 | Previous: 4bee180 | Ratio |
|---|---|---|---|
peak memory |
1580.176 MB |
1566.871 MB |
1.01 |
peak threads |
355 threads |
364 threads |
0.98 |
network (transport) |
2724.77 MB |
2730.605 MB |
1.00 |
disk write |
1.461 MB |
1.449 MB |
1.01 |
instructions |
115.497 G |
115.402 G |
1.00 |
This comment was automatically generated by workflow using github-action-benchmark.
Codecov Report❌ Patch coverage is
@@ Coverage Diff @@
## main #4612 +/- ##
==========================================
+ Coverage 81.21% 81.75% +0.53%
==========================================
Files 1651 1641 -10
Lines 154436 153716 -720
Branches 13017 13024 +7
==========================================
+ Hits 125431 125676 +245
+ Misses 25424 24463 -961
+ Partials 3581 3577 -4
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 48 files with indirect coverage changes 🚀 New features to boost your workflow:
|
…pture-time joint state and tf, point fields kept, late captures dropped) folds into it and point_cloud_self_filter.py goes; masking is optional (self_filter, on by default)
 [High impact] Renames and refactors the point cloud self-filter module. Not safe to merge until mesh requests are processed without silently dropping distinct requested files. Findings
SummaryThis PR replaces
Fix the mesh-request delivery failure before merging: clients can remain waiting for files needed to complete the robot view. Reviews (1) · Last reviewed commit: "UrdfManager: one module poses a URDF fro..." · Reviewed by Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| async def handle_mesh_request(self, request: String) -> None: | ||
| # Only meshes the URDF names: a request is never a path into the filesystem. | ||
| path = self._mesh_paths.get(request.data) | ||
| if path is None: | ||
| logger.warning(f"mesh_request for {request.data!r}, which is not a mesh in urdf_info") | ||
| return | ||
| self.mesh_info.publish(MeshFile(request.data, await asyncio.to_thread(path.read_bytes))) |
There was a problem hiding this comment.
When a client requests several robot meshes, the automatically connected handler keeps only the latest waiting request. While this handler awaits a file read, requests for other meshes overwrite each other and never receive a mesh_info response. A check through the actual stream sent four distinct requests while the first read was blocked; all four reached the input, but only the first and last files were returned. A client waiting for every mesh can therefore stall or display an incomplete robot.
This needs to be fixed before merging. Process mesh requests through a lossless queue rather than the latest-only dispatcher, and add a burst regression test through the actual stream wiring.
Artifacts
Executed mesh-request burst test
- The authored test loads snapshot source and exercises real Module stream and dispatcher plumbing with a gated file read, making the dropped-request check reproducible.
- Started the base snapshot's predecessor module and inspected its live stream declarations, showing that the mesh endpoint did not exist before this PR.
Mesh-request loss at PR #4612 head
- Ran sequential controls followed by four distinct requests during a blocked read, showing that all requests arrived but only the first and last files were returned.
Mesh-request loss at PR #4379 head
- Executed the identical burst test against the supplied PR r1pro-nav-lio: depth2depth + kronk nav #4379 snapshot, showing that it still drops the two intermediate requests.
Mesh-request loss at PR #4613 head
- Executed the identical burst test against the supplied PR r1pro-nav: arm planning #4613 snapshot, showing that it still drops the two intermediate requests.
Executed source and higher-stack comparison
- Captured git source, relevant blob identities, mesh-reference searches, and unchanged checkout refs, showing that neither higher-stack snapshot replaces the lossy implementation or adds a resolving caller.
…erwise only at unchanged_tf_hz (4 Hz), not the whole tree at 30 Hz; the keepalive stays under twice the tightest tf lookup tolerance of its readers
github-actions
Bot
added
the
ready-to-merge
… and a mesh_request whose ?hash= is already current gets no reply, so a client can cache meshes and only fetch stale ones
github-actions
Bot
removed
the
ready-to-merge
… that requests the name urdf_info gives (with its ?hash=) still gets the file
github-actions
Bot
added
the
ready-to-merge
…very 0.2 s), so a client that just connected doesn't wait out the 5 s period
github-actions
Bot
added
ready-to-merge
This branch was successfully deployed
1 participant
UrdfManager poses a URDF from joint state, publishes its joints on tf and cuts the robot out of point clouds, replacing RoboPlanPointCloudSelfFilter (split out of jeff/feat/r1pro_nav).