Dear MoveIt! developers,
After updating my Ubuntu packages (and later cloned the latest kinetic-devel branch) I keep getting the error 'std::runtime_error' what(): Duration is out of dual 32-bit range after almost each successful plan execution. The error is encountered both by sending goals from rviz and code.
Thanks for any kind of help,
George
This could be due to an incomplete update of your ROS pkgs. The latest Kinetic sync seemed to have introduced an ABI break and as a result a lot of ppl report this and other similar problems.
See Time is out of dual 32-bit range fi.
Thanks for the lightning fast reply. I tried compiling my catkin workspace again, but had no chance. Based on your hint, it might be any of the binaries I already have installed, so it might be "automatically" fixed in the next kinetic sync. Did I get that right?
The first thing to check is whether you've upgraded all your ROS pkgs. So sudo apt-get upgrade should not show any ROS pkgs with outstanding updates.
Sorry my answer was not detailed enough. Before trying to compile my catkin workspace, I tried upgrading but apt found nothing new.
(0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.)
I'm not claiming it is the reason, but because of all the other reports of ABI breaks it was a good thing to check.
You're reporting this issue with both the current .debs as well as a source build, correct?
Thanks for your help. You are correct, I have the latest binaries and the latest source. I will keep an eye on ROS answers and on the issues here, for candidate solutions.
Thanks again.
To be more precise: A complete, clean rebuild of the workspace is required, not just compiling again. We also ran into this a few days ago.
@skohlbr wrote:
To be more precise: A complete, clean rebuild of the workspace is required, not just compiling again. We also ran into this a few days ago
Yes, indeed.
However, as the OP reports the same issue with the latest .debs, it seems unlikely this is the same ABI break as reported on ROS Answers (unless the .debs have not been properly rebuilt).
To be more precise: A complete, clean rebuild of the workspace is required, not just compiling again. We also ran into this a few days ago.
Thanks for joining in, on the discussion. I followed your advice and just finished compiling with a clean workspace (removed both build and devel folders). Unfortunately the problem persists.
This is a pretty impressive incompatibility, do we have any clue what caused it? My working hypothesis so far is that something of the timestamp format inside joint state messages changed?
We observed crashes/exceptions in both robot-state-publisher and move-group when we connected an outdated UR driver package. But shouldn't changes to message format be handled by checksums? Was that debug mode only?
I'm still not convinced this is not the ABI incompatibility.
We have a large nr of Q&As on ROS Answers about this and it's almost always resolved by updating all packages and rebuilding the workspace.
A simple catkin b doesn't work, you'll have to really clean it out first then rebuild.
I cleaned all of my catkin workspaces, updated all my packages and had no chance. I tried this routine everyday, before starting to work on my regular stuff, and suddenly yesterday I had no crashes. I am not sure if I was lucky or it was actually fixed, but it seems to be fine for now...
I got this issue. Tried many things but nothing worked. Finally uninstalled and reinstalled ROS. Now everything is fine
Hi, I have got the same issue but its not consistent. MoveIt retime_trajectory throws this error from time to time (once in 100-300 runs).I have recently installed ros (on a docker) so all packages should be new. I have installed by ubuntu repositories i.e apt-get install.
I am also encountering the same issue on ROS Melodic running on Ubuntu 18.04.
@rahulbhadani, please follow the instructions in this thread, i.e. cleaning and rebuilding your workspace from scratch.
I was using 18.04, in my ros node, ros rate was not defined ! Defining it worked.
Most helpful comment
To be more precise: A complete, clean rebuild of the workspace is required, not just compiling again. We also ran into this a few days ago.