[ros-users] ROS Clients that work out of the box without ROS .msg, .srv, and .action pre-compilation

Tim Niemueller niemueller at kbsg.rwth-aachen.de
Tue Jan 6 10:31:36 UTC 2015

Hi Aaron.

We have always been doing that in roslua and actionlib_lua. Works nicely
and is fast. It also allows for introspection of messages, a feature
that the C++ lib is painfully missing.

For mongodb_log I have had the idea to automatically generate loggers
based on .msg files generating C++ code and piping it through a compiler
and run it (acknowledging the general pattern you see in the specialized
C++ loggers in combination with the general but slow
introspection-capable Python logger). But that has not materialized due
to time constraints, though I'm confident it is easily doable -- and
similarly if not even simpler in Java.


On 06.01.2015 06:22, Aaron Sims wrote:
> Dear ROS-Users,
> I've been working on a ROS Client implementation in Java that does not
> require pre-compilation of .msg, and .srv (.action may or may not happen
> based on implementation requirements - I haven't researched enough to
> know if it has any special requirements).
> The .msg, and .srv can be compiled on the fly based on the message
> definition in most cases, and the implementers of ROS appear to of went
> to great lengths to ensure this potential functionality, by also
> including and nested Object type on the initial communication (Or maybe
> this is only done in turtlesim..., I assume not since turtlesim .msg
> definitions do not contain the additional Object types, this is a ROS
> specific technical implementation).
> Do the C++, and Python ROS Clients implement the functionality to
> convert incoming ROS Messages on the fly to native Objects? Or do they
> work in a similar manner to ROS Java requiring that a client manually
> compile the the .msg, and .srv files, then using those precompiled APIs,
> or are they smart enough to automatically write their own input and
> output data handler and auto generate their own Native Object for
> interpretation by the autonomous, semi-autonomous, or teleoperation
> controller?
> If this functionality is not implemented, the designers put in an
> awesome Easter Egg.
> Thanks,
> Aaron
> _______________________________________________
> ros-users mailing list
> ros-users at lists.ros.org
> http://lists.ros.org/mailman/listinfo/ros-users

KBSG - Knowledge-based Systems Group            AllemaniACs RoboCup Team
http://robocup.rwth-aachen.de                     RWTH Aachen University
http://kbsg.rwth-aachen.de                               Ahornstrasse 55
http://www.fawkesrobotics.org                             D-52056 Aachen

More information about the ros-users mailing list