Adding ROS2 support in robocompdsl (Design)
This post will talk about how we shifted from “Porting innermodel lib from C++ to Python” to “Adding
ROS2 support in robocompdsl (Design)” and what this project is all about. Later we will talk about
the problems that
robocompdsl already had, problems with ROS1, and how we changed some of the design
of the component.
So this project “Python3 binding for innermodel” was inteded to be for porting all the InnerModel APIs from C++ to Python using PyBullet and Numpy. We worked vigorously about 1.5 months, when we realised that it will be finished way before the time. So we began considering to work on other projects of which we choose
robocompdsl. So, if anybody don’t know what
robocompdslis, it is the most important and one of the first robocomp tools that you are going to interact with when starting with robocomp.
robocompdslis a tool to generate a component from a .cdsl file. At the time
robocompdslwas quite basic, only able to generate components with ICE middleware and the parser was quite broken. It couldn’t even do the things it was supposed to do like creating components with ROS middleware.
So our aim with the new project “ROS2 support for robocompdsl” was to first fix the ROS1 support and then add the support for ROS2.
One of the first things that I noticed in the initial stages of development was that many features of the
robocompdslthat it was supposed to do were not working. The
.cdslparser was broken. We couldn’t specify which middleware to use in the component. It wasn’t working for even ICE. So I had to fixed that first.
The generated code for ROS1 was not even compiling, so I had to first fix ROS1 code generation and then move on to the ROS2.
For ROS2 one of the major challenges was to figure out how to compile it with cmake. Since ROS2 is different from ROS1 in a considerable way, and so was its build system.
The second most important difference was the way in which ROS
msgs/srvsare built in both ROS versions. In ROS1 we have a script that can generate the necessary header files for
srvfiles and then built those for the
msg/srvheaders to be included in the
genericworker.h. While on the otherhand it is very complicated in ROS2 to directly generate the headers file because of the inherent design of the ROS2 which uses 3 different implementation DDS protocol. Something like this cant be handled by a single python script and so cmake MACROs are used instead.
Next problem was not with the ROS2 but with ROS1, the inconsistent design with different communi- cation modes (
publishes, subscribesTo, implements, requires). For example: for
publishesmode in ROS1 there is a dedicated class of publishers with the name of interface specified, while for the
subscribesTomode in ROS2 there are callbacks written inside the
GenericWorkerclass which makes it inconsistent. So what I have done is make a class for all the modes. A single class will handle all the things ROS. This class is instantiated in
GenericWorkerclass and can be used through it.