Add noetic-devel branch to merge working port to

[arne48]

I ported the stdr_simulator to noetic and have found no issues so far. GUI works, Robot adding works, sensor publishing and control via teleop_twist_keyboard works, rviz shows data as expected.

My port is based on the newest indigo-devel. As QT5 is now used I think it would make sense to create a branch for future versions using QT5. I would be hesitant to create a PR to indigo-devel because I expect it to break the compatibility with all earlier releases.

My noetic-devel branch can be found here: https://github.com/arne48/stdr_simulator

Maybe it can be tested from there and if you would like to integrate it, I would be happy to help with that.

[xhding1997]

Good job my friend ! It works well on my Noetic ! Thanks for your work ! :100:

[aabuaish]

@arne48 Thanks for making the changes. Unfortunately, I was not able to get STDR simulation to work on my Ubuntu 20.04 machine with ROS neotic, although I was successful in running STDR simulation on a different machine with Ubuntu 18.04 with ROS melodic. I cloned this repo: https://github.com/arne48/stdr_simulator.git I get the following error when the robot_handler node is run or launch server_with_map_and_gui_plus_robot.launch:

[stdr_server-3] process has died [pid 90787, exit code -11, cmd /home/aabuaish/catkin_ws/devel/lib/stdr_server/stdr_server_node /home/aabuaish/catkin_ws/src/stdr_simulator/stdr_resources/maps/sparse_obstacles.yaml __name:=stdr_server __log:=/home/aabuaish/.ros/log/2e94c504-070f-11ed-afe6-3da9dea6dbb2/stdr_server-3.log].
log file: /home/aabuaish/.ros/log/2e94c504-070f-11ed-afe6-3da9dea6dbb2/stdr_server-3*.log

Then, I get an error message Could not spawn robot on the terminal if I ran server_with_map_and_gui_plus_robot.launch or in a dialog box if I load the robot from the GUI. From your description, it seems that the issue is to do the version of QT. I have both qt4 and qt5 installed. I tried compiling with both qt4 and qt5 using the following commands, yet I got the same error above.

$ catkin_make -DQT_QMAKE_EXECUTABLE=/usr/bin/qmake-qt4
$ catkin_make -DQT_QMAKE_EXECUTABLE=/usr/bin/qmake-qt5

Everything appears to work normally using the provided launch files or by rosrun different nodes. The problem is with the robot_handler_node. Would you know by any chance the source of this error and how to fix it?

Your help is much much appreciated.

[arne48]

Thank you for testing this branch @aabuaish. Without more information it would be hard to diagnose your problem. I just tested the package on my noetic test machine and couldn't reproduce the error you are describing. An "# ldd /home/aabuaish/catkin_ws/devel/lib/stdr_server/stdr_server_node" would be interesting. About your concerns in regards to the qmake version it would be interesting to know if you installed it via repository and which versions exactly you have. However, at least the "stdr_server_node" isn't using QT resources or linked to any qt library so I am not sure that this is the right direction to look for. As far as I know only stdr_gui is using QT and should also specifically use QT5 but I am not sure if their could be hiccups if both are installed. Therefore, also a gdb backtrace would be helpful. Lastly I don't really understand these two points you made: 1.__I get the following error when the robot_handler node is run or launch server_with_map_and_gui_plus_robot.launch 2.Everything appears to work normally using the provided launch files__ Which provided launch files are working if you say that _server_with_map_and_gui_plusrobot.launch doesn't.

IMPORTANT EDIT: I just read you issue again and noticed that the error message doesn't seem to be consistent with your error description. Your snippet is about the _stdr_servernode but you suspect _robothandler. However, your _stdr_servernode seems to have died due to an segfault (exit code -11). So I wonder if there was a mix-up of some sort. In any case we have to debug this.

[aabuaish]

Excellent! I will take a closer look at your comments and the error messages. Many thanks

[aabuaish]

Hi there,

Sorry for the late follow up. I ended up using my Ubuntu 18.04 machine to use STDR to meet my deadline. However, this week I debugged the code, and the issue is due to the Boost library version. I had versions 1.5x.xx and 1.71.xx on the Ubuntu 18.04 and 20.04 machines, respectively. The code line 638 in file stdr_simulator/stdr_server/src/stdr_server.cpp caused the run time crash. Particularly the method call in the if statement

ros::Duration(5.0).toBoost()

I simply replaced that ROS-based duration object with the boost duration object

boost::posix_time::seconds(5)

Now STDR works fine.

[arne48]

@aabuaish, sorry for the extremely long response time. I saw that you found a fix that worked for you and then just occasionally remembered about this.

As said it is good that you found a solution for your problem. Could you debug a bit further and could find out the root cause for it? Because if there is additional potential for the port of STDR it would be a good idea to add them for others as well so that they don't have fix it them-self based on the entry in this issue.

I am asking about the root cause because the actual implementation on Noetic for "toBoost" looks like this:

_roscppcore/rostime/include/ros/impl/duration.h

   template <class T>
   boost::posix_time::time_duration
   DurationBase<T>::toBoost() const
   {
     namespace bt = boost::posix_time;
 #if defined(BOOST_DATE_TIME_HAS_NANOSECONDS)
     return bt::seconds(sec) + bt::nanoseconds(nsec);
 #else
     return bt::seconds(sec) + bt::microseconds(nsec/1000);
 #endif
   }

So as you can see the produced code should be comparable to yours except the addition of nano/microseconds. It would be good to know if there is a problem with with the duration implementation or the way it is used inside of STDR. However, for now if someone experiences the same difficulties your solution might worth a try for them. :)

I am looking forward to your answer and maybe a small summary of your debugging process.