Skip to content

Allow Transformations to be aware of a "fixed frame" #1522

@jleibs

Description

@jleibs

Rerun currently only looks up transform-chains using the latest-at value for the given scene.

However, there are many situations where this doesn't produce the correct results. In particular, the case sensor-readings that are different from an odometry update the judder artifacts are quite clear:
Screencast from 02-27-2023 07_58_23 PM.webm

The crux of the problem is the points are observed in the robot frame. So to place them in the map frame, we apply the transform map_T_robot. However, map_T_robot is being updated at a much faster rate (based on odometry) and so our current "latest at" logic ends up using points from time t with multiple transforms observed at t+1, t+2, etc.

The right thing to do here is to instead build up the transform chain specifically using historical transform values at the time of the data being transformed (including interpolation if the robot odometry measurements and point-cloud measurements didn't line up exactly).

However, it's important to note that this isn't always the right behavior. Whether transforms are treated as having a fixed frame needs to be configurable. This seems like a good candidate for an EntityProperty. If the "fixed frame" entity property is set, rather than using the current latest-at behavior, we would decompose the transform chain into two pieces:

dest_T_source = dest_T_fixed @ T_render * fixed_T_source @ T_source

The solution for this should also take into account visible history: #723

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions