rviz plugin retrieving .ply instead of .stl form DB. Bad mesh shown. about object_recognition_ros

[awesomebytes]

I have the same experience, I did this little change:

    if (object_info.has_field("mesh_uri")){
      mesh_resource = object_info.get_field<std::string>("mesh_uri");
      std::stringstream ss;
      ss << "mesh_resource contains: " << mesh_resource << "\n";
      ROS_WARN("%s", ss.str().c_str());
      mesh_resource.replace(mesh_resource.find("cloud.ply"), mesh_resource.length(), "mesh.stl");
      ss << "Replaced cloud.ply for mesh.stl, now contains: " << mesh_resource << "\n";
      ROS_WARN("%s", ss.str().c_str());
    }

And effectively, now the correct mesh is showing.

I'm tracking down where this info comes from, and mesh_uri becomes filled here:
https://github.com/wg-perception/object_recognition_ros/blob/master/src/info_cache/info_cache.cpp#L121

But I see no evidence of .ply being writen anywhere (I've done a grep -r ply in ork_ros).

Ok, kept debugging, when running the line:
https://github.com/wg-perception/object_recognition_ros/blob/master/src/info_cache/info_cache.cpp#L121

object_info_ptr->has_field("mesh_uri")

Gave me TRUE.

object_info_ptr->has_attachment("mesh")

Gave me FALSE.

So it won't execute the code that references to .stl... so, what is filled in there then? Seems to come from before, maybe at the training/meshing? I'll keep looking into it.

[awesomebytes]

Thanks to @vrabaud we fixed this issue with this commit:
wg-perception/object_recognition_core@991cdac