Dear Aaron,

to the best of my knowledge, there is no problem with having a ros
client library compile message and service definitions on-demand. In
our lab, a group of students experimented with this for clojure last
year. What might be relevant for you from their experience is that
they came up with a grammar for ROS messages. You can find the grammar
in their PRE-ALPHA project here:

https://github.com/code-iai/asimov/blob/master/src/asimov/message.clj

To answer your other questions:
- As far as I'm aware, there is no support for on-demand message
compilation in c++.
- There should be such functionality implemented in the python client
implementation. All the command line tools written in python behave as
if they build messages at runtime. However, I'm not a ROS python expert.
- Finally, with on-demand compilation of messages supported in your
client library, you can also compile actions on-demand.

Cheers,
Georg.


On 01/06/2015 06:22 AM, 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@lists.ros.org 
> http://lists.ros.org/mailman/listinfo/ros-users
> 

_______________________________________________
ros-users mailing list
ros-users@lists.ros.org
http://lists.ros.org/mailman/listinfo/ros-users