geometry: Retrieve AABB and OBB for a GeometryId from QueryObject

[RussTedrake]

I would like to be able to get an oriented bounding box (just the actual box, not the OBB tree) for a GeometryId given a SceneGraph and a Context. Presumably this would go through the QueryObject, but I'll leave the design decision to you.

I would like to use this OBB as a simplified version of the collision geometry for a planning algorithm I am working on now (imagine avoiding collisions with the OBB instead of the true geometry, which is the simplest use case). I believe it will also prove valuable in providing ground truth labels for training some perception algorithms.

Based on a conversation this afternoon with @sherm1, it sounded like this is probably a fairly small ask. Please let me know if it's not.

[SeanCurtis-TRI]

This is certainly a reasonable request. The single biggest obstacle is that Obb is currently in internal:: namespace. So, we'd either have to pull Obb out of internal or return the Obb information in some other means. Pulling Obb out implies pulling Bvh and Aabb out as well. So, I'll look more directly into the implications of doing that and get back to you.

The nice thing is, producing an Obb for the primitives is trivial (we can guarantee an optimal Obb). In fact, just about anyone could. The big benefit will be bounding arbitrary meshes/convex shapes that may not have such arbitrary symmetry.

[RussTedrake]

Thanks. Even for the primitives, this would be very useful to me. I could write the OBBs myself, but I don't want to (in every application)!

[RussTedrake]

I've read through more of the code, and found aabb.h and obb.h. I'm hoping to have access to both, please. (will update the issue title)

[jwnimmer-tri]

Broadly, the QueryObject seems to offer functions that return results typed as T scalars, but the current Oobb and Aabb classes are hardcoded to double. We should be clear about what scalars should be allowed for (at compile time) as part of this change.

I could see the case for the half_width remaining double, since our ShapeSpecification is double, but it seems like at least the pose (and center) should be on T?

[RussTedrake]

Good point. My use case only requires double for now, and if supporting T is a challenge, I'd be happy to see the double-only version land first.

[jwnimmer-tri]

To be clear, I have no problem with throwing on AutoDiffXd. My point is that if we foresee having Aabb<T> or Oobb<T> down the road, then we should make those into class templates now, because changing them once they are part of the the public API is a big hassle.

[SeanCurtis-TRI]

I'm also in the midst of touching the BVH infrastructure (in support of deformable simulation) and would rather not have to thrash that PR train with these kinds of changes. That PR train is progressing nicely, and I'll come back to this when it's done.