search

SoMa-Project / vision

Contains the WP4 vision code developed in TUB for the planner.
Other
3 stars 1 forks source link

Vision master branch is breaking the IFCO frame convention #18

Closed ptriantd-ocado closed 6 years ago

ptriantd-ocado commented 6 years ago

@SoMa-Project/tub We noticed that the master branch is breaking the IFCO frame convention. More specifically, the ifcoWall0 frame has the x axis pointing upwards instead of the y. However, the published MarkerArray is following the convention and so does the wall frame that is acquired from the graph.

rviz_screenshot_2018_04_11-09_42_17

In the Ocado branch though, we followed the convention for the ifcoWall0 frame and as a result the produced MarkerArray is incorrect and so is the wall frame of the graph.

I guess we could brake the convention for ifcoWall0 as well, but we believe that the wall frames should be consistent throughout the the tf - MarkerArray - planner level.

ptriantd-ocado commented 6 years ago

It seems that the broadcasted ifcoWall0 frame has no effect to the MarkerArray after all (but the inconsistency should be fixed).

Changing line 586 of IfcoGrasp.cpp (Ocado branch) from biggestNormal = tf::Vector3(ifcoRotation(0,2), ifcoRotation(1,2), ifcoRotation(2,2)); to biggestNormal = tf::Vector3(-ifcoRotation(0,2), -ifcoRotation(1,2), -ifcoRotation(2,2)); seems to fix the issue, but it is counter-intuitive because the static ifco frame broadcasted in the case when the TUB ifco detection is bypassed is the same as the one published by ecto when the TUB ifco detection is not bypassed.

zweistein commented 6 years ago

I think the ifcoWall0 and ifcoWall1 are debug frames in the TF tree and not in the /geometry_graph_marker MarkerArray. Those two frames are old debug frames and they are very specific for our IFCO detection. We didn't apply the bugfix #6 on these two frames.

The correct wall and surface frames (which are also passed through the ECE graph) visualised are in the /geometry_graph_marker MarkerArray (only when vision is launched in debug mode).

We need to remove these two frames from ecto.

ptriantd-ocado commented 6 years ago

Ok, then the only issue is why biggestNormal is different in the two cases. More specifically why the normal of table_fits/bounded_model_biggest is opposite from the z axis of the ifco tf.

zweistein commented 6 years ago

I'm not sure about the biggestNormal, @JessyVision do you?

However, the original issue is going to be fixed with merge request #19. Also, have a look at the soma_utils latest merge #85 and in debug mode please use the ece_graph_markers topic to visualise the frames.

ptriantd-ocado commented 6 years ago

The issue is that in the Ocado branch, which is a branch of the ocado_ifco_toMerge_master the wall frames in the MarkerArray are incorrect (the y is pointing downwards instead of upwards). Initially I assumed that this had to do with the ifcoWall0 tf, but now it is clear that it does not. It has to do with the biggestNormal which is different when TUB vision is used compared to when our vision is used. I will close this issue and open a new one.