alextoind's profile - activity

Since I've started using ROS few years ago, I used to simplify my life with basic templates like the following:

int main(int argc, char** argv) {
  ros::init(argc, argv, "my_node");
  my_namespace::MyNode my_node;  // includes a ros::AsyncSpinner
  ros::waitForShutdown();
  return 0;
}

where everything is started in the MyNode() constructor, for example by retrieving custom configurations from the Parameter Server.

Now, that I've started to gamble on the Google Testing/Mocking Framework for my projects, things are getting complicated.

I know that I have to test first the core libraries using only gtest in a ROS agnostic way and then the nodes behaviour and interoperation using both gtest and rostest. Nonetheless, if MyNode has several public non-static methods, I must initialize a class object to access them from the TEST macros, and this become ROS dependent. Moreover, if my node is aimed to control hardware, I usually initialize the communication in the constructor to avoid to start it manually each time. This can be also a problem because it forces me to stay with the device connected while testing (which is ok for higher level testing, but not for unit testing).

What is the best way to strucutre a ROS node to easily test it properly? I could set a new public method start() with the major things of the constructor (e.g. device communication setup) and call il from within the main, but I'm not very convinced about it... Should I extract MyNodeImpl from MyNode and test that one?

EDIT: further thoughts...

1. I was wrong with the PIMPL approach because even if it separates the code in a way that I could like for my purpose (and which has also other known advantages), it also hides the code that I'd like to test. I know that you should test only the public interface, yes, but it's not always the case.
2. On the other hand, if I separate the hardware setup and all those stuff in another public method called from within the main, I do not resolve the ROS dependency of the unit test, i.e. if you have a ros::NodeHandle as a member of the class you need to initialize ROS first.
3. A very-ugly-but-quick workaround could be the one to add a specific fake protected constructor of the class and use it only for testing. This could be a simple empty constructor with a specific parametrization, obviously different from the others. A part from the ugliness, the real drawback is that this method is accessible by derived classes and yet, it is not ROS agnostic.

I'm a bit frustrated... I mean, testing should help, not be the trouble. Anyway, if you have any suggestion I'm all ears!

You are great! I had few delays in the project so it is perfectly on time :D And, as you said, the PDO mappings were the

JetBrains CLion IDE setup for ROS I've downloaded it a couple of days ago, but I still have not figure out how to config

@mgruhler thanks for the feedback! I've not started to work on it yet, but I'll try with SOEM then and I'll let you know

@mgruhler have you come up with something shareable? I have got an Elmo DC Whistle too and I'll need to integrate it in

If you are still interested, have a look at https://github.com/ros/ros_comm/pull/1354.

It seems that the joint_state_publisher is not able to mimic another mimic joint.

Traceback (most recent call last):
File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner self.run()
File "/usr/lib/python2.7/threading.py", line 754, in run self.__target(*self.__args, **self.__kwargs)
File "/opt/ros/kinetic/lib/joint_state_publisher/joint_state_publisher", line 212, in loop joint = self.free_joints[parent]
KeyError: u'<recursive_joint_name>'

The problem is addressable to the clear distinction between free and dependent joints, i.e. if a joint is dependent, it cannot be taken as reference for anyone else.

I see that this is not a real problem as I can mimic the base joint with the proper reduction multiplier. Nonetheless it becomes annoying with a long chain and it also could be not very intuitive at first glance.

I think that the best solution is to implement this workaround without creating an extra non-free-but-neither-only-dependent category which could only mess up with the code.

I also think that I'm going to create a pull request in the following days, have you got any suggestions?

EDIT: Here is (possible?) simple modification of the part of interest:

# Add Dependent Joint
elif name in self.dependent_joints:
    param = self.dependent_joints[name]
    parent = param['parent']
    factor = param.get('factor', 1)
    offset = param.get('offset', 0)
    while parent in self.dependent_joints:
        param = self.dependent_joints[parent]
        parent = param['parent']
        factor *= param.get('factor', 1)
        # the offset is relative only to the first parent
    joint = self.free_joints[parent]

@David Lu, do you think it could work?

I have tried to find an updated answer with the best practices when dealing with ROS and C++11/14, but everything is messy or out of date...

0 - Setting the C++ standard directly [DEPRECATED]

I know that the quicker way to enable C++11/14 is to add in the CMakeLists.txt one of the following macros

cmake_minimum_required(VERSION 2.8.3 FATAL_ERROR)
...
set(CMAKE_CXX_FLAGS "-std=c++11")
set(CMAKE_CXX_FLAGS "-std=c++14")

even with all the possible checks (see the many answers on SO or this one). Nonetheless it is written everywhere - apparently not enough though - NOT to set CMAKE_CXX_FLAGS (e.g. catkin docs).

So I have searched a bit more to find some updated guidelines for cmake and C++11/14 like the followings: [1], [2], [3], [4]. It comes out that since cmake v3.1/3.2 there are two main methods which overcome the CMAKE_CXX_FLAGS manual setup.

1 - Setting the C++ standard directly

The standard C++11/14 can be specified directly and the *_REQUIRED protects the building from potential compiler errors if the standard is not supported.

cmake_minimum_required(VERSION 3.2.0 FATAL_ERROR)
...
set_property(TARGET target1 target2 ... PROPERTY CXX_STANDARD 11)  # 98, 11 or 14
set_property(TARGET target1 target2 ... PROPERTY CXX_STANDARD_REQUIRED ON)

References: [5], [6], [7].

Otherwise the CMAKE_* variables specify the properties for all the targets in the CMakeLists.txt ([8], [9]).

2 - Setting the C++ standard based on features

If a finer tuning or a higher control is required, the right C++ standard can be set from the features which are really used in the code. This is surely more accurate, but it requires time to be properly set (lots of features) and can be fragile if not supported correctly over time.

cmake_minimum_required(VERSION 3.2.0 FATAL_ERROR)
...
target_compile_features(myTarget
  PUBLIC
    cxx_variadic_templates
    cxx_nullptr
    ...
  PRIVATE
    cxx_lambdas
    ...
)

References: [10], [11].

Note

In every docs regarding ROS you always find cmake_minimum_required(VERSION 2.8.3) which is fine to guarantee that our code could be compiled even with older cmake version, and everybody seems happy.

The current version of cmake shipped with Ubuntu 16.04 and ROS Kinetic (both LTS, and hoping the new standard for at least a couple of years) is the 3.5.1. The drawback of allowing such an old cmake compatibility is the unkown behaviour in not tested old systems (which is the case of almost every small project). Indeed another best practice for cmake usage is to set the minimum required version to the lower testable one.

The question is: what is ROS waiting for to increase the minimum requirements to at least cmake v3.2 and to improve docs with updated best practices?

I've bumped into the same problem and I think the behavior is still the same as three years ago. @Sebastian Kasperski, h

I've downloaded it a couple of days ago, but I still have not figure out how to configure it correctly to work with ROS.

If I import a simple ROS project it gives me the following error, but I can compile (and run) it from the terminal:

Error: By not providing "Findcatkin.cmake" in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by "catkin", but CMake did not find one.
Could not find a package configuration file provided by "catkin" with any of the following names:
  catkinConfig.cmake   catkin-config.cmake
Add the installation prefix of "catkin" to CMAKE_PREFIX_PATH or set "catkin_DIR" to a directory containing one of the above files.  If "catkin" provides a separate development package or SDK, be sure it has been installed.

I'd like to know where to properly set these environmental variables and how can I get the equivalent of catkin_make from inside the IDE.

Thanks in advance!

EDIT 29.11.2018

After more than three years, thanks to this post and to a couple of similar ones, JetBrains has published an official guide for CLion 2018.3 (which is fine also for previous versions).

You can find it here: https://www.jetbrains.com/help/clion/...

The two main approaches described in the comments above are both valid. For my specific application I've chosen to creat

Hi all, I don't know if it is a bug or the default behavior, but I was using the _namespaced include_ for the first time and I am a bit confused. I have done something like the following to avoid name clashes:

<xacro:include filename="$(find my_pkg)/urdf/my_macros_1.xacro" ns="my_namespace_1"/>
<xacro:include filename="$(find my_pkg)/urdf/my_macros_2.xacro" ns="my_namespace_2"/>

<xacro:my_namespace_1.build_model my_param="something_useful_for_1">
  <origin xyz="0 0 0" rpy="0 0 0"/>
</xacro:my_namespace_1.build_model>
<xacro:my_namespace_2.build_model my_param="something_useful_for_2">
  <origin xyz="0 0 0" rpy="0 0 0"/>
</xacro:my_namespace_1.build_model>

However it turns out that the name clashes still exist:

unknown macro name: xacro:build_model_part
XacroException(u'unknown macro name: xacro:build_model_part',)

where build_model_part is another macro called inside the two utility files.

The only workaround that I found is to add the namespace inside _my_macros_1.xacro_ (using my_namespace_1) and _my_macros_2.xacro_ (using my_namespace_2) to every single macro call. This obviously avoid name clashes, but I would have called the macros respectively build_model_1 and build_model_2 instead of applying the namespace inside all the calls...

Where is my mistake?

Based on @otamachan answer, this is my working configuration on Ubuntu 16.04 with ROS Kinetic, gtest (libgtest-dev v1.7.0-4ubuntu1) and gmock (google-mock v1.7.0-18092013-1):

# Tests
if(CATKIN_ENABLE_TESTING)
  find_package(rostest REQUIRED)

  # explicit gmock build (set these paths properly!)
  include_directories(/usr/include/gmock /usr/src/gmock)
  find_library(GMOCK_LIBRARIES libgmock)
  if(NOT GMOCK_LIBRARIES)
    add_library(libgmock /usr/src/gmock/src/gmock-all.cc)
  endif()

  add_rostest_gtest(my_test
    test/my_test.test
    src/test/my_test.cpp
    ...
  )

  target_link_libraries(my_test
    libgmock
    ${catkin_LIBRARIES}
  )
endif()

It seems that the problem has been simplified since gmock does not include gtest anymore.

EDIT: as shown in the launchpad, the google-mock package for Ubuntu Xenial depends on libgtest-dev (>= 1.6.0). Actually it does not includes gtest even since Ubuntu 14.10 (Utopic Unicorn). Unfortunately, Ubuntu 14.04 is shipped with google-mock v1.6.0+svn437-0ubuntu5 (see the package) which includes gtest inside; indeed, it depends on nothing but python.

EDIT2: added a simple check to avoid multiple add_library(libgmock ...) from distinct packages.

I know that I've been a bit slow on the uptake, but I got it. Thank you very much, you are great!

And - if I understand correctly - if I decide to switch to plugin approach, I'll use it "forever". Could this be a problem in some circumstances? Sorry if I'm boring you, but it's a remarkable restyle and I just want to be sure that it won't be useless.

Why should I use something which behave like nodelets instead of using nodelets itself? I mean, start from scratch takes time and probably leads to a similar result. Are there any particular reasons to prefer this way (apart the perfect fitting to my problems, if well designed)?

Thank you for helping me once again! I was just reading about nodelets which I have never used before. It seems to do the trick, but I have to dig a bit more the get the whole picture.

Suppose that I have some devices which can be assembled as a chain and which communicate with a single serial port (each device has its own unique id and a proper firmware). These devices can be also very different from each other, both in shapes and functionalities, but share the same hardware (i.e. the same low level API can be used for all of them).

Now you are a forward-looking programmer and you know that what you are developing for a specific purpose will be used for many other projects. You prefer modularity rather than the one-size-fits-all approach. And you also like ROS.

Suppose you develop a base interface to wrap the low level API and implement on top of it the specific device classes. Now, because of the multi-device environment, it is desirable to avoid putting everything inside a single ROS node, in favour of a modular and easily customizable one-node-for-one-device approach (i.e. using ad-hoc launch files for distinct configurations).

Everything is fine.

Everything but the managemant of the serial communication from distinct nodes. Indeed ROS is a multi-process environment and distinct processes do not share resources each other: the file descriptor of the single serial port cannot be shared.

Actually the open() on the same resource can be called by distinct processes if the exclusive mode is not set (cf. ioctl() with TIOCEXCL and TIOCNXCL options). However, this implies a synchronization mechanism, and again, sharing something among processes.

1. How would you face this problem?
2. Are there any workaround in ROS which I do not know?
3. How much overhead w.r.t. to a single I/O operation would produce a communication handler "super-node" (e.g. with read(), write(), ... ROS services)?

@roboticom314 with Xenial you would be fine: it is not a matter of ROS version. However, @joq is right.

@Dirk Thomas sorry for the typo, it's obviously that way - as shown in the other answer. Edited, thank you!