ray_tracing: place clouds purely through tf - #3596
Draft
jeff-hykin wants to merge 7 commits into
Draft
Conversation
jeff-hykin
commented
Aug 21, 2026
jeff-hykin
commented
Member
- place clouds purely through tf; drop the odometry input
- previously clouds were dropped at the odom pose, ignoring the sensor mount: a camera half a metre up and angled down put the floor in the wrong place
- tf lookup at each cloud's stamp resolves world_frame -> sensor frame through the mount edge
- cargoHash refresh to unstick the nix build
Codecov Report✅ All modified and coverable lines are covered by tests. @@ Coverage Diff @@
## main #3596 +/- ##
=======================================
Coverage 77.10% 77.10%
=======================================
Files 1262 1262
Lines 120300 120301 +1
Branches 10634 10634
=======================================
+ Hits 92758 92762 +4
Misses 24461 24461
+ Partials 3081 3078 -3
Flags with carried forward coverage won't be shown. Click here to find out more.
... and 3 files with indirect coverage changes 🚀 New features to boost your workflow:
|
The pinned hash no longer matches what vendoring the lockfile produces, so `nix build` fails in the fixed-output vendor derivation and RayTracingVoxelMap cannot start at all. Reproduced on an untouched checkout of main.
… pose on_lidar registered camera-frame points into the world using only the odometry pose, so the base_link -> camera_color_optical_frame mount never applied. The ESKF roll error used to cancel it; with odometry level the map came out rotated. Resolve the mount once from tf (held clouds until it arrives) and start rays at the sensor origin instead of the body center. The offline transformer.py variant still has the odom-only registration.
Look up world_frame <- cloud.frame_id at each cloud stamp and register points and the ray origin through that one transform, fresh every cloud. The old path paired clouds with buffered odometry poses and assumed they were already in the body frame; the map now accumulates and publishes in config.world_frame instead, odom on alfred. Clouds must arrive in their own sensor frame and the odometry source must put its world->body edge on tf, which OdometryFusion does. The offline python binding takes pre-transformed points and passes an empty world_frame.
jeff-hykin
force-pushed
the
jeff/fix/ray_tracing_tf
branch
from
August 21, 2026 10:48
76d1ad8 to
c8e8540
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.