Marker load mesh resource success, but not show in window?

[ghost]

Environment:

• OS: Ubuntu 20.04
• ROS version: ROS noetic
• RVIZ version: 1.14.9(QT version 5.12.8, OGRE version 1.9.0(Ghadamon))
• Tip: Windows 11(wsl2 with wsl CUDA driver / 2060 super )

#!/usr/bin/env python3
import rospy;
from visualization_msgs.msg import Marker;

if  __name__ == "__main__":
    frame = 0
    rospy.init_node('kitti_node',anonymous=True)
    model_pub = rospy.Publisher('car',Marker, queue_size=10)

    while not rospy.is_shutdown():
        marker = Marker()
        marker.header.frame_id = "map"
        marker.lifetime = rospy.Duration();

        marker.type = marker.MESH_RESOURCE
        marker.mesh_resource = "package://kitti/Car-Model/frame.dae"
        marker.action = marker.ADD
        marker.scale.x = 80
        marker.scale.y = 80
        marker.scale.z = 80

        marker.color.r = 0.4
        marker.color.g = 0.2
        marker.color.b = 0.8
        marker.color.a = 1

        marker.mesh_use_embedded_materials = False
        marker.pose.position.x, marker.pose.position.y, marker.pose.position.z = 0, 0, 0
        marker.pose.orientation.x, marker.pose.orientation.y, marker.pose.orientation.z, marker.pose.orientation.w = 0, 0, 0, 1
        model_pub.publish(marker)
        rospy.loginfo("kitti published")

[rhaschke]

Does it work in a non-WSL environment? If so, I suspect the WSL environment.
If not, check that the message is actually received by rviz. Are other shapes, e.g. boxes, spheres displayed?

[ghost]

I don’t have a physical machine, I test shape, boxes, e.g. All this can be displayed normally.

[rhaschke]

Did you try another mesh as well?

[rhaschke]

Closing due to missing feedback and because the issue isn't reproducible on default platforms.

[peci1]

I guess this is due to using a non-English locale which does not have decimal point but e.g. decimal comma (as my cs_CZ happens to have, too). I confirm that running rviz with my czech locale, objects smaller than 1 meter (before scaling) are not shown at all as rviz reads 0.12345 as 0<GARBAGE>, which gets converted to 0 in the end. When this happens for all vertices, you get a nice singulartiy.

Try running rviz with LANG=C and it should get fixed.

These locale-dependent problems are ever-occuring in both RViz and Gazebo. Wouldn't it be easier to set locale to English right after starting RViz? There's anyways no translation of it, so the only difference would be that users would see floating point numbers in the property tree rendered in English locale instead of their own (which I'd consider a feature and not a problem).

[peci1]

After some discussion in #1682 I suggest to reopen this bug (although I face it on Melodic).

@simonschmeisser

If your workspace is all from code a grep for std::stof or std::stod might tell

Nope, I run on binary packages from APT... The latest update of liburdfdom-dev on my system was in February 2021, so this should not be the cause (although I can't say for how long have I not used custom mesh markers).

[simonschmeisser]

urdfdom should not be involved here at all actually as we talk about markers. But they are certainly not the only ones using those innocent looking functions ...

[rhaschke]

@peci1, could you please provide more details about your setup as well as your marker mesh file? Thanks.

[peci1]

[ INFO] [1637671619.373657592] [ros.rviz]: rviz version 1.13.21
[ INFO] [1637671619.373710951] [ros.rviz]: compiled against Qt version 5.9.5
[ INFO] [1637671619.373722126] [ros.rviz]: compiled against OGRE version 1.9.0 (Ghadamon)
[ INFO] [1637671619.390423505] [ros.rviz]: Forcing OpenGl version 0.
[ INFO] [1637671619.623746375] [ros.rviz]: Stereo is NOT SUPPORTED
[ INFO] [1637671619.623813213] [ros.rviz]: OpenGL device: AMD RENOIR (DRM 3.42.0, 5.15.4-051504-generic, LLVM 13.0.0)
[ INFO] [1637671619.623830953] [ros.rviz]: OpenGl version: 4.6 (GLSL 4.6) limited to GLSL 1.4 on Mesa system.

Ubuntu 18.04 on x86_64, ROS Melodic from APT binary packages (including rviz).

$ locale
LANG=cs_CZ.UTF-8
LANGUAGE=
LC_CTYPE="cs_CZ.UTF-8"
LC_NUMERIC="cs_CZ.UTF-8"
LC_TIME="cs_CZ.UTF-8"
LC_COLLATE="cs_CZ.UTF-8"
LC_MONETARY="cs_CZ.UTF-8"
LC_MESSAGES="cs_CZ.UTF-8"
LC_PAPER="cs_CZ.UTF-8"
LC_NAME="cs_CZ.UTF-8"
LC_ADDRESS="cs_CZ.UTF-8"
LC_TELEPHONE="cs_CZ.UTF-8"
LC_MEASUREMENT="cs_CZ.UTF-8"
LC_IDENTIFICATION="cs_CZ.UTF-8"
LC_ALL=

[peci1]

Here are the meshes I'm trying to visualize meshes.zip.

For example:

$ rostopic pub -l /marker visualization_msgs/Marker "header:
  seq: 0
  stamp: {secs: 0, nsecs: 0}
  frame_id: 'base_link'
ns: ''
id: 0
type: 10
action: 0
pose:
  position: {x: 1.0, y: 2.0, z: 3.0}
  orientation: {x: 0.0, y: 0.0, z: 0.0, w: 1.0}
scale: {x: 1.0, y: 1.0, z: 1.0}
color: {r: 0.0, g: 0.0, b: 0.0, a: 0.0}
lifetime: {secs: 0, nsecs: 0}
frame_locked: false
points: []
colors: []
text: ''
mesh_resource: 'file:///tmp/meshes/drill.dae'
mesh_use_embedded_materials: true"

[rhaschke]

@peci1, your meshes are broken, requiring a pre-open interaction, e.g. when opening in meshlab:

I guess that confuses assimp as well. rviz shows an appropriate error message:

[rhaschke]

@peci1, can you please check again, if you can reproduce the locale issue by some other means?

[ghost]

Localization environment is zh-Hans or zh-CN(Simplified Chinese) in the scene I encountered.

[peci1]

My Rviz doesn't have the problems with opening the marker:

with LANG=C:

with LANG=cs_CZ:

The fact that Meshlab asks for what geometry nodes to display is pretty normal with Collada. I don't remember a single time when it would just open a Collada file without askin. These meshes work pretty normally in Gazebo.

[peci1]

I'll try to construct a simple mesh that manifests the problem, too.

[peci1]

Even this super-simple blender-exported cube manifests the problem: box.zip. What's interesting is that when I change <unit name="centimeter" meter="0.01"/> for <unit name="meter" meter="1"/> in the collada, the mesh is shown even in Czech locale. Changing unit to e.g. 0.99 still manifests the problem. So I think the unit is still parsed using a locale-dependent function (I don't know where, though).

[peci1]

@thinkershare Can you check the units of the meshes you try to display?

[simonschmeisser]

Meshes could be loaded via assimp, using the github search (very unreliable) tells me that only colors for X3D files should be broken in assimp on non English locales but no further use of std::stof/stod. They have their own implementation of atof which seems to be locale agnostic (good!). It's not used everywhere (bad!). But not in Collada it seems (maybe? please check yourself)

rviz also does some collada parsing here:

rviz/src/rviz/mesh_loader.cpp

Line 634 in 45e5a9b

if (unitXml->QueryFloatAttribute("meter", &unit_scale) != 0)

[peci1]

Very good intuition! I just tested it and unit_scale is changed to 0 in this call with unit smaller than 1.

[simonschmeisser]

This uses tinyxml2 which boils down to sscanf which is ... locale dependent ... TADA!

Basically TinyXml(2) is broken and in other places the argument is read as string and then parsed manually:
moveit/srdfdom@a4564a5
and
https://github.com/ros-planning/moveit/pull/1099/files

[peci1]

Fix in #1684. @thinkershare Can you confirm this fix fixes your issue, too?

[ghost]

Yes, now it works fine.

[rhaschke]

Fixed via #1685.