-
Notifications
You must be signed in to change notification settings - Fork 510
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
[Bug Fix] Fixing rotational bug in tasks.rearrange.utils.get_camera_transform
#1847
base: main
Are you sure you want to change the base?
Conversation
tasks.rearrange.utils.get_camera_transform
tasks.rearrange.utils.get_camera_transform
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.
LGTM! If would be nice if you could add a comment or flag about how this was computed before so that I can make sure my skill training code is correct and I will fix them.
Based on offline conversations:
|
@jimmytyyang @xavierpuigf Please take a look at this change as it directly touches your agent functions. @aclegg3 Pushed the changes we discussed, please take a look and leave comments. However, let's not merge this until Xavi has taken a look and approved. I already walked Jimmy through this and I think the code changes will support his use-case. |
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.
This looks much better, thanks for the fix. 👍
I'll request that you add some typing/docs and I suggest you don't worry about backward compatibility unless there is a known down-stream user to accommodate.
We can merge when @xavierpuigf approves.
As an aside, I think this util function could be unit tested in test_robot_wrapper.
rot_offset = articulated_agent.offset_transform_base.inverted() | ||
link_trans = articulated_agent.base_transformation @ rot_offset | ||
# else: | ||
# raise Exception( |
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.
Keeping or leaving this exception logic?
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.
I want to keep it but running into a LOT of cyclic import problems when I try to use typing in this function.
This function is used in manipulator.py
however, the arguments of this function are inherited children of Manipulator
class. So if I add types, it leads to manipulator.py
ending up importing Manipulator
in-turn. We could just use Manipulator
as the arg-type here but that is very generic and does not let us add guardrails like the exception I commented out. (importing KinematicHumanoid
was leading to a cyclic import issue).
Is there some better code organization we could do here?
def get_articulated_agent_camera_transform_from_cam_info( | ||
articulated_agent, | ||
cam_info, | ||
): | ||
# Get the camera's attached link |
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.
Please add type hints and a docstring to clarify the parameters and expose to the web API docs
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.
See the problem mentioned above with typing :(
cam_trans = link_trans @ offset_trans @ cam_info.relative_transform | ||
cam_trans = None | ||
|
||
if deprecated_logic: |
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.
Interesting strategy. Do we need this? Are there active down-stream use cases we are tracking?
IMO We can change the logic without back-compat and mark this PR as a breaking change since it is so close to the last release.
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.
I agree with this. I think @jimmytyyang is the only known down-stream user who was using this function. I walked through his code with him and I do not think this change should affect him. He was using the pose to do ray-casting from the center of the camera, this function only adds in-plan rotation which should not upset his logic.
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.
sounds good to me! priyam you made a call for this!
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.
Thanks! I'll take this out so we have a cleaner code-merge.
Co-authored-by: Alexander Clegg <[email protected]>
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.
LGTM, thanks! Agreed that if we don't use the decprecated logic, it may be fine to remove it
…f/get-cam-transform-fix
Motivation and Context
Fixes issue #1804
How Has This Been Tested
Tested with zf/obs-wm-updates branch of habitat-llm. Following is the relevant driver code:
Check fixed point-clouds generated through this method in this PR comment.
Types of changes
Checklist