search

wg-perception / tabletop

conversion of the old tabletop stack to ecto
7 stars 24 forks source link

Fix object pose by removing redundant z_min correction. #15

Closed toliver closed 10 years ago

toliver commented 10 years ago

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:

rviz_object_recognition_bad_z

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):

rviz_object_recognition_good_z

awesomebytes commented 10 years ago

I tested this change and it effectively does what it says. Proof: Before this patch: screenshot from 2014-04-14 12 32 30

After this patch: screenshot from 2014-04-14 12 31 09

@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 commented 10 years ago

@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 https://github.com/wg-perception/object_recognition_ros/issues/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 commented 10 years ago

@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. screenshot from 2014-04-15 13 07 54

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 commented 10 years ago

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).

mesh

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 commented 10 years ago

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 commented 10 years ago

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

vrabaud commented 10 years ago

@hris2003 , did that ever get fixed ?

hris2003 commented 10 years ago

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" notifications@github.com wrote:

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

— Reply to this email directly or view it on GitHub https://github.com/wg-perception/tabletop/pull/15#issuecomment-60534275.

vrabaud commented 10 years ago

Still seems broken to me .... tmp

hris2003 commented 10 years ago

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 notifications@github.com 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 https://github.com/wg-perception/tabletop/pull/15#issuecomment-60537826.