-
Notifications
You must be signed in to change notification settings - Fork 17
Feature: Utility Options #38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
mbpeterson70
commented
Nov 23, 2025
- add option to use a static tf that is published in /tf in data_params
- allow skipping non-overlapping submaps and self loop closures
- make the offline rpgo result plot nicer
| if not np.isnan(robots_nearby_mat[i, j]): | ||
| relative_yaw_angle = transform_to_xyzrpy(T_ij)[5] | ||
| submap_yaw_diff_mat[i, j] = np.abs(np.rad2deg(relative_yaw_angle)) | ||
| if submap_distance > sm_io.skip_distance: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Consider moving this after the submap_descriptor calculations, so that submap descriptor similarity is still saved?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I like that, sounds good.
roman/params/data_params.py
Outdated
| ) | ||
| # by default looks for a static tf, but if the user wants to reference a tf that is | ||
| # theoretically static, but is published under /tf, then 'try_non_static_tf' can be set. | ||
| if param_dict.get('try_non_static_tf', False): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The naming 'try_non_static_tf' makes it sound like it would look under both /tf_static and /tf as a fallback. Maybe just get rid of the param and use a try/catch fallback instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haha that's actually what I was doing before but I realized that PoseData.from_bag_tf is basically a super-set of any_static_tf_from_bag, so if the user is okay with the fact that they might be putting in a transform in their tree that shows up in /tf then we might as well use the PoseData.from_bag_tf. What do you think about renaming from try_non_static_tf to include_non_static_tf ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure!
* update readme with static_tf changes