Fix object pose by removing redundant z_min correction.

[toliver]

The min_z is subtracted twice.

First the mesh vertices are offset so that z=0 is the minimum for the mesh (in https://github.com/shadow-robot/tabletop/blob/a107a368d019557b69b77f281561fd80a8ac528b/src/object/ObjectRecognizer.cpp#L184)

Then the pose found for the object is offset again, leading to a wrong position for the object, as shown in the following image:

Using the correction in this pull request the pose is in the right place (see the cam RGB image on the right side of the rviz screen):

[awesomebytes]

I tested this change and it effectively does what it says. Proof:
Before this patch:

After this patch:

@toliver I'm noticing that your mesh from OrkObject is correctly visualized. Did you fix that? I have this gray big things appearing around. Also, does the detection work with many objects for you?

[toliver]

@awesomebytes Yes, sorry about that. I should have said that the mesh was correctly shown because of a quick dirty hack that I did to get around wg-perception/object_recognition_ros#15

As per the detection, I have only tried with 2 different objects in the DB for the moment. And they were correctly recognised, but I haven't tested this bit very thoroughly (i.e. with other unknown objects involved).

[awesomebytes]

@toliver It's nice you showed the mesh thingy working as we got to fix it yesterday thanks to that.

I have an energy drink bottle, a mug, a pringles can and an aquarius can for now. The pringles are detected all the time, but the rest of the stuff very rarely.

If you could try with a couple more objects it would be great. If it works for you I'm maybe doing something wrong.

[toliver]

Hi @hris2003. I have just had a look at the code in this commit again (although I'm unable to test it right now) and I am not sure that it makes sense.

I don't know why it did solve my issue (but it did).

The tabletop node is reading a mesh from DB, then subtracting the minimum z to it and adding it to the object recognizer.
The object recognizer returns a pose for the recognized object (https://github.com/shadow-robot/tabletop/blob/a107a368d019557b69b77f281561fd80a8ac528b/src/object/ObjectRecognizer.cpp#L339) and then the original code subtracted the min_z to the found pose of the object. Which makes sense, as we are going to return the pose associated to the DB object_id, and the pose in the DB will not necessarily have a min z = 0. So it is actually right to subtract the min_z again.

But for some reason this logic behaviour didn't work for my object as shown in the screenshots further up.

Here you can see the position of the object mesh I was using w.r.t the z axis. (it is 2 or 3 cm above the xy plane).

I would need to dig a bit deeper to find out what happened but I can't do it right now. Sorry.

I can make the mesh available to you if you want to give it a try.

[vrabaud]

Thx for the answer. Actually, we figured out that assimp opposites the z values when loading the mesh .... So that will be fixed in a patch soon.

[toliver]

Well, that certainly explains the offset. (Sorry for introducing a new bug :S )

[vrabaud]

@hris2003 , did that ever get fixed ?

[hris2003]

Yes, the current version of tabletop fixes that issue. Users need to pay
attention to the origin point of their meshes though, because rviz bases on
that to do the viewing.
On 26 Oct 2014 23:02, "Vincent Rabaud" [email protected] wrote:

@hris2003 https://github.com/hris2003 , did that ever get fixed ?

—
Reply to this email directly or view it on GitHub
#15 (comment).

[vrabaud]

Still seems broken to me ....

[hris2003]

From my experience, the rendere coke mesh in rviz depends somehow on the
mesh'origin point. The returned pose from tabletop only give infors about
the position and orientation of the recognized object, and the rviz will do
the viewing. For example, if your coke mesh looks like this:
[image: Inline image 1]

then in rviz you have the mesh viewed as in your case (mesh going thought
the table).

If you have a mesh like this:
[image: Inline image 2]
then in rviz you will have something like this:

[image: Inline image 1]

So, tabletop users need to be careful about the mesh origin of their
objects.

There're sure several way to make rviz render the mesh correctly on the
table, but then again the designer needs to make it clear with the users
about the infors in the resulted pose (e.g. the point designated as the
position of the object: In the center of mass of the object? Right under
the object in the midle or on the left/right?

Personally, I prefer letting the user decide the origin of their mesh when
they model it (in blender or whatever the software) so that it's up to them
to choose the origin's position as they want.

Ha.

On Mon, Oct 27, 2014 at 12:45 AM, Vincent Rabaud [email protected]
wrote:

Still seems broken to me ....
[image: tmp]
https://cloud.githubusercontent.com/assets/700766/4784873/2eea0d72-5d6a-11e4-8662-bb61349954a4.png

—
Reply to this email directly or view it on GitHub
#15 (comment).