MoveIt! RViz display plugin does not show the robot correctly (Melodic)

Question

Hello!

I recently upgraded my system to Ubuntu 18.04 and Melodic, installing both ROS and MoveIt! from deb. I have some issues with MoveIt!'s display plugin, as shown in the picture below. I generated the config package for this Kuka LWR from scratch by running the setup assistant, but the same problem appears with "pre-existing" configuration packages.

• bottom left: the robot as shown by MoveIt!'s MotionPlanning display (current state + goal state in violet)
• top: robot shown via the "standard" RViz RobotModel display

When running the demo.launch, I can set the goal state to a random configuration, plan and execute using the MotionPlanning panel. The interactive marker does not work instead (but I guess it is just a side effect). The only warning I get on the terminal is the following (I run the demo.launch with the debug option enabled):

[ WARN] [1530806517.103186724]: Interactive marker 'EE:goal_p3r3_link_6' contains unnormalized quaternions. This warning will only be output once but may be true for others; enable DEBUG messages for ros.rviz.quaternions to see more details.

Since I just switched to Melodic and I don't trust myself, my guess is that I missed something from the migration guide (or elsewhere), but I cannot figure out what.

Thanks in advance! Has anyone experienced the same issue already? The only warning I get when starting

---

Originally posted by ffusco on ROS Answers with karma: 271 on 2018-07-05

Post score: 2

Answer 1

I finally figured out what was the issue! It is related to urdfdom and how it parses floating point values. The problem had been fixed, however it seems that the fix is not yet available in Melodic. This causes RViz to mishandle URDF-related plugins. The problem is reported, eg, here, and a quick solution is to change the environment variable LC_NUMERIC so that a point is used as decimal separator: export LC_NUMERIC="en_US.UTF-8". In France the default definition was fr_FR.UTF-8, which assumes commas as decimal separator, and this caused plugins to wrongly interpret the URDF.

---

Originally posted by ffusco with karma: 271 on 2018-07-09

This answer was ACCEPTED on the original site

Post score: 7

---

Original comments

Comment by Long Smith on 2018-08-24:
Thanks! Just encountered the same problem.

Comment by tahsinkose on 2019-08-21:
Is this LC_NUMERIC only a ROS component or does it affect other parts of the system?

Comment by ffusco on 2019-08-21:
It is an environment variabile of the system, which might affect other applications. As an example, an application like Libre Office Calc might read its value to decide what decimal separator should be adopted. In any case, since the day I added such export to my barshrc I have never experienced any issue due to it :)