-
Notifications
You must be signed in to change notification settings - Fork 478
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
"on_floor" query util #1841
"on_floor" query util #1841
Conversation
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, Alex! Left some comments/questions.
object_id_b: int, | ||
ao_link_map: Dict[int, int] = None, | ||
ao_aabbs: Dict[int, mn.Range3D] = None, | ||
) -> float: |
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 function isn't used in on_floor. Do we have a use case for it? Why introduce it with on_floor?
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, we could wait to merge this with "nearby". That is were it really belongs.
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.
Actually, this is already cleaned and tested. I'm going to merge it now given that nearby will be added soon. Less work in the long-run. Would be different if not tested.
|
||
assert isinstance( | ||
object_a, habitat_sim.physics.ManagedRigidObject | ||
), "Object must be ManagedRigidObject, not implemented for ArticulatedObjects or links." |
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.
Just checking -- do we have use cases for AO on_floor?
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 don't think so because we don't support AO "pick-able" objects presently. I currently assume all AOs are furniture or robot/human.
:param sim: The Simulator instance. | ||
:param obj_id: The integer id of the object or link. | ||
:param ao_link_map: A pre-computed map from link object ids to their parent ArticulatedObject's object id. | ||
:param ao_aabbs: A pre-computed map from ArticulatedObject object_ids to their local bounding boxes. If not provided, recomputed as necessary. |
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.
for my understanding, this is bounding box for a closed articulated object?
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 is a map of all AO bounding boxes for the scene. It includes the state of the links when computed.
Typically, if pre-computed at initialization it will be for closed AOs (unless non-default AO states are specified in the scene instance config).
If it is computed in this function or re-computed during simulation, it "could" include the open state of the receptacles if they are currently open.
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.
looks good overall.
Just a clarification: the floor and the navmesh are the same in this abstraction? If yes, does this affect how we initialize objects on floor? Would they be initialized anywhere on the navmesh, which might include things like unsegmented furniture?
Correct, the navmesh is our model of the valid floor space here. It is true that an inaccurate navmesh could result in false positives. Like you say, using the entire navmesh could, for example, allow bed or sofa tops to be considered floor in some scenes. There are controls available to prevent this. Primarily the |
* add get_bb_for_object_id function * add get_object_size_along and minor doc adjustments * add size_regularized_distance function * add on_floor function and tests
* add get_bb_for_object_id function * add get_object_size_along and minor doc adjustments * add size_regularized_distance function * add on_floor function and tests
Motivation and Context
This PR adds the
on_floor
utility function for heuristically checking whether an object is "on the floor".Context: we want to know if objects are on the navigable area of the floor for rearrangement. This function checks that the heuristic point-to-surface distance between the object and its nearest navmesh snap point is within an error threshold.
Supporting utilities:
get_bb_for_object_id
- a generic utility for getting the local bounding box and transform of any object or link from its object_id integer.get_obj_size_along
- a function to approximate the object's size in a particular global direction from its bounding box size. Uses aabb scale to transform the vector, essentially finding a point on the best-fit ellipsoid within the aabb.size_regularized_distance
- a function to get estimated surface-to-surface distance between two objects or links using theget_obj_size_along
function to truncate the center-to-center distance between the objects.Also includes a few minor refactors to other utilities.
How Has This Been Tested
Added a set of pytests.
Types of changes
Checklist