Closed toliver closed 10 years ago
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?
@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).
@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.
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.
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.
Well, that certainly explains the offset. (Sorry for introducing a new bug :S )
@hris2003 , did that ever get fixed ?
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.
Still seems broken to me ....
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.
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):