Standalone C++17 ROS1 client

ROS Projects
,
1

Good day, colleagues.

I would like to present a standalone version of C++17 ROS1 client, which does not need boost, catkin or any complicated external library to build. Just CMake and c++17 compiler is enough.

The goal of this project is to provide relatievely small embeddable ROS1 client to be used in a projects, which already have their own constraints on build systems or libraries and catkin/boost/python is already too much.

Miniros is a monolithic version of roscpp, where everything boost:: was replaced either by an std:: variant or a local adaptation.

It also uses special gencxx message generator, which produce pure std:: code. Headers for all standard message and service types is included directly into miniros. It should be enough to read almost all standard datasets for SLAM. Unfortunately, you still need some catkin workspace to generate code for new types of messages or services.

Additionally, recent v0.5 version has its own C++ reimplementation of roscore (master+rosparam+rosout).

Problems for now:

  1. Theoretically it should work on windows, but I do not have any windows/MSVC machine to test and fix problems.
  2. Code is based on ros1 melodic (project started in 2020) and a lot of bugfixes from noetic should be backported.
  3. minirosbag supports only “play”, “record”, and “encrypt” commands. No “minibag info” for now.
  4. Setting log levels is not in a healthy shape right now.
  5. Only a small subset of tests from ros_comm is adapted.

Future plans:

  1. Add some multimaster functionality to local implementation of roscore.
  2. Replace ancient xmlrpc with more tightly-integrated version.
  3. Consider adding rosbridge functionality directly to transports.

I hope that even in the current state the project can be helpful. Any help with testing will be also very welcome.

4 Likes
2

Miniros v0.6.0 is released

Key features:

  1. Experimental IP/hostname resolver inside miniroscore.

Master can try to extract IP addresses of all connecting nodes and provide URI with direct IP addresses in the response. It helps with setting ROS1 network in absence of a proper DNS resolution for all network nodes.

Unfortunately, standard roscpp and rospy nodes still report their “hostname” URI in "/requestTopic " when subscriber talks directly to a node. Even if master gives good IP address of a publisher to a subscriber. So standard publishers will not this automatic name resolution (It can be easily fixed in standard roscpp/rospy, but since it goes EOL, nobody should expect that).
Standard subscribers will connect properly if they talk with “miniros” nodes. I.e RViz will draw all data from miniros node without proper DNS setup, or standard navigation will work with “minibag play euroc_whatever.bag”.

  1. General bugfixing in miniroscore.

There were a plenty of protocol issues in miniroscore implementation. Since it was initially based on ROS.Net implementation of master, it had a lot of issues and incompatibilities with standard python implementation.

  1. More roscpp tests were adapted from rostest suite.

All test executables from roscpp testing suite were migrated to miniros. Unfortunately, most of these executables are part of rostest scripts and not useful directly. I really do not want to rely on rostest to verify protocol, so there is a lot of work ahead.

  1. Windows support had some attention.

Now miniros compiles with both MSVC-19 and mingw. Github CI checks that now. Though, no big testing is done.

  1. Updated gencxx and all headers for standard messages.

This update fixes warnings with deprecated allocator_traits on newer compilers.

Plans for near future

  1. Finish migration of testing suite and run it on CI.
  2. Do proper support for windows.
  3. Introduce minimal multimaster functionality inside miniroscore. Multiple masters should be able to discover each other and share registration info with each other.