You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
The solution for this should also take into account visible history: #723
The text was updated successfully, but these errors were encountered: