[ros-users] ROS Groovy, Catkin, Message Generation
Christian Holl
choll at synapticon.com
Tue Jan 8 10:50:06 UTC 2013
Hi,
First of all: congratulations for completing this new release! As I’m
dealing with writing a new ROS client library, the first and main look I
took within this release was into Catkin. For what I can tell up to now, I
see some good change here but unfortunately there are a lot more points I
do not like…
Let’s start with the good thing I see: the messages are now generated in
the user’s workspace, what is really good when looking at adding a new
“language” like rosc, the one I’m working on, where every message in every
package has to be built for the new language which wasn't possible if using
installed packages before.
Now to the critics.
When using rosbuild, everything you have to do to create a new language was
making your language package depended on roslang and adding a tag which
specifies the generator function.
Now it seems that you have to create a file inside a special directory to
make the compiler notice that there is a new language, unfortunately it's a
system directory. The message generator (which creates the same files as
before) now uses EmPy instead of just a python script. I don't have used
EmPy so far but I think that's ok. What feels weird to me is that the
generator is generated by another generator residing inside genmsg (the
base of message generation) containing language specific details for python
and cpp, which I think, should be only inside gencpp or genpy. Otherwise
somebody (like me) who wants to write another language add-on has to mess
around inside basic ros stuff (I really dislike messing around inside a
doubled generator btw). If there is another possibility to add another
language to the build toolchain, please tell me! It would be cool to have
message stuff automatically generated for different languages. Another
strange thing is, that the build python script for roscpp is placed in
another directory than the templates for it.
I guess the best way for message generation would be to stay the old way
for calling the generator by just adding a tag inside the package.xml
making it a language package instead of defining it on other places and and
use the python scripts of ROS for reading the message files and merge that
with the new location in the users workspace. Then everybody could add add
a new language easily.
Now to the general usability when creating a package.
When using rosbuild and wanting to generate messages (or services), you
just had to remove a comment in front of the generation line. Now instead
of a usability improvement so that it automatically looks for files inside
the msg/srv directory, you have to specify which directory the files reside
in, each message and additionally the dependency for them. Also you have to
specify each dependency of the package,additionally to the dependencies
inside the package.xml where you have to also add some lines for generating
messages. This really introduces much complexity on the user side and is
really uncomfortable for creating new packages. I think that shouldn't be
necessary.
Additionally the fact that I have to change to the catkin workspace
directory to build one package really annoys me, please make some script
which builds from any package directory or anywhere for the current
workspace.
Btw, what general advantage does catkin bring, besides generating messages
inside users directory? Currently I do not see any other big advantage
compared to rosbuild. But perhaps I’m blind, so please help to see! ;-)
One more thing which I’m not quite sure about: is catkin added as a new
method to build ros packages or shall it completely replace rosbuild?
Currently both seems to be supported somehow in the documentation.
Regards,
Christian
Reference:
*http://www.ros.org/wiki/ROS/Tutorials/CreatingMsgAndSrv*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osuosl.org/pipermail/ros-users/attachments/20130108/626570df/attachment-0003.html>
More information about the ros-users
mailing list