-
Notifications
You must be signed in to change notification settings - Fork 1
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
BoundingBox3DType
is not generic over frames in which the bounding box is used
#142
Comments
I am a proponent of creating a function |
Thanks for raising this limitation of the BoundingBox3DType. This was indeed something I did not consider/design the datatype for. However, your request of being able to transform bounding boxes is certainly valid and useful for all airo-mono users. Background and Current Limitations Possible Solution: Introducing a OrientedBoundingBox3DType = Tuple[BoundingBox3DType, HomogeneousMatrixType] Considerations and Next Steps
|
I think we also want to have AABBs and OBBs. Still, both kinds of bounding boxes can be transformed (e.g., AABB: expressed w.r.t. which axes?) in Open3D also: Open3D's OBB class has a constructor that creates OBBs from a center, rotation matrix and extents in X, Y and Z directions. Its AABB class is similar to airo-mono's I see two options if we want to add wrapper functions around transformations for both types.
|
I agree that this is a useful 'tool' to have. However, I think it is important to
|
That is a fair point @tlpss. In airo-mono itself, I want to raise this as a discussion point, either with @Victorlouisdg directly, or in our upcoming meeting. I'll add it to the agenda in any case. |
5 months later, I see no other use cases in airo-mono for OBBs, in applications I've been mostly using Open3D directly. My proposal is to close this issue and keep |
In some cases, we want to define a bounding box in the object's local frame, as this makes it easy to reason about
minimal
andmaximal
points that define theBoundingBox3DType
.It is of course possible to do this, but if we then want to use this bounding box in another frame, e.g., to log it in rerun or to add it to a simulation in drake, we need to transform the bounding box points.
We cannot simply transform the two points with
transform_points
, because minimum and maximum points in one frame may not be the minimum and maximum points in another frame.One solution is to compute the eight corners of the bounding box, transform these, and recompute the minimum and maximum points. For example:
We could create a function that performs these operations. Alternatively, is there some representation of a 3D bounding box that does not have this issue but is still easy to work with?
The text was updated successfully, but these errors were encountered: