gazebosim / gazebo-classic

Gazebo classic. For the latest version, see https://github.com/gazebosim/gz-sim
http://classic.gazebosim.org/
Other
1.16k stars 476 forks source link

GetBoundingBox returns the models' last collisions bb #1325

Open osrf-migration opened 9 years ago

osrf-migration commented 9 years ago

Original report (archived issue) by Andrei Haidu (Bitbucket: ahaidu).

The original report had attachments: kitchen_table.zip


The returned bounding box of a model is the one of its last collision, this might have been overlooked in this issue (#841).

Code snippet (world plugin in the Load method):

#!c++

void WorldPluginEx::Load(physics::WorldPtr _world, sdf::ElementPtr _sdf)
{
    std::cout << _world->GetModel("KitchenTable")->GetBoundingBox() << std::endl;
}

I also attached the KitchenTable model.

osrf-migration commented 9 years ago

Original comment by Andrei Haidu (Bitbucket: ahaidu).


osrf-migration commented 9 years ago

Original comment by Z F (Bitbucket: yzfang).


similar to https://osrf-migration.github.io/gazebo-gh-pages/#!/osrf/gazebo/issues/1205/incorrect-model-boundingbox (#1205)

osrf-migration commented 9 years ago

Original comment by Steve Peters (Bitbucket: Steven Peters, GitHub: scpeters).


osrf-migration commented 9 years ago

Original comment by Elte Hupkes (Bitbucket: ElteHupkes).


I just ran into this issue after getting incorrect bounding boxes for Model::GetCollisionBoundingBox(), after some digging I found out why that happens so I figured I'd report it here; it applies to Model::GetBoundingBox() as well.

The issue is that the bounding boxes returned by the collision implementations (BulletCollision::GetBoundingBox() and ODECollision::GetBoundingBox()) have an extent of EXTENT_NULL, because they are created with their argument-less constructors. Looking at Box::operator+() / Box::operator+=(), we see that if the extent of a box is EXTENT_NULL, it simply inherits the min/max values of the box it is being summed with. Since all of the boxes in the bounding box sum have EXTENT_NULL, the result is practically the same as taking the last box in the sum.

There is an additional issue with Entity::GetCollisionBoundingBox() (which is what Model and all other Entity's use) which occurs when there is at least one child which does not contain collision elements (e.g. a joint in the case of a model). In this case the default argument-less constructed box will be returned for this item, which will have min/max vectors of (0, 0, 0). Depending on the situation, these might actually be out of the range of the current min/max vectors, extending the bounding box. Combined with the previous issue it gets even worse: if the last child of a model is a joint, Model::GetCollisionBoundingBox() will return that last value, i.e. a box of size 0 in all dimensions.

So to fix all of this:

osrf-migration commented 9 years ago

Original comment by Elte Hupkes (Bitbucket: ElteHupkes).


Okay, apparently my previous comment only solves part of the problem. The returned bounding boxes also seem to depend on the underlying physics engine in a non-compatible manner. ODECollision::GetBoundingBox() shows an attempt to return the bounding boxes in world coordinates (which is what you want for AABB's) but depending on the rotation of the object this value is either a little bit or completely wrong - and I'm clueless why. BulletCollision::GetBoundingBox() on the other hand returns the bounding box in the collision's (or link's, not sure) reference frame, which makes it completely useless for summing it with the other bounding boxes (a bounding box of a rotated object is not equal to the rotated bounding box of the original object).

Unfortunately I've no time to delve into this deeper now, there's a master's thesis involving simulated robots I have to work on which will just have to do without bounding boxes for now ;).

osrf-migration commented 7 years ago

Original comment by Nate Koenig (Bitbucket: Nathan Koenig).